Криптопро java csp и криптопро jcp в чем отличие
Криптопро java csp и криптопро jcp в чем отличие
Реализация КриптоПро JCP совместима с КриптоПро CSP.
Средство криптографической защиты КриптоПро JCP распространяется в двух комплектациях:
КриптоПро JCP предназначен для:
Алгоритм выработки значения хэш-функции реализован в соответствии с требованиями ГОСТ Р 34.11 94 «Информационная технология. Криптографическая защита информации. Функция хэширования» и ГОСТ Р 34.11 2012 «Информационная технология. Криптографическая защита информации. Функция хэширования».
Алгоритмы формирования и проверки ЭЦП реализованы в соответствии с требованиями:
Алгоритм зашифрования/расшифрования данных и вычисление имитовставки реализованы в соответствии с требованиями ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая» и ГОСТ 34.12-2015 «Информационная технология. Криптографическая защита информации».
При генерации закрытых и открытых ключей обеспечена возможность генерации с различными параметрами в соответствии с ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012.
При выработке значения хэш-функции и шифровании обеспечена возможность использования различных узлов замены в соответствии с ГОСТ Р 34.11-94/ГОСТ Р 34.11-2012 и ГОСТ 28147-89.
КриптоПро JCP функционирует в следующем окружении:
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2001):
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2012, 256 бит):
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2012, 512 бит):
Длина ключей, используемых при шифровании:
Типы ключевых носителей:
Криптографическая архитектура Java
Стандартные спецификации Java 7, предоставляют стройную систему криптографической защиты информации (ПКЗИ). Более подробно эта архитектура развёрнута по следующим ссылкам:
Как использовать
КриптоПро JCP разработан в соответствии с требованиями интерфейса JCA и позволяет создавать новые, надежно защищенные приложения с использованием богатейшего и проверенного временем инструментария Java такого, как Apache XML Security для ЭЦП XML-документов стандарта XMLdsig.
Рекомендации к окружению
Для пользовательских приложений рекомендуется использовать лицензированные Sun виртуальные машины J2SE полностью удовлетворяющие требованиям спецификации Java 7. Для серверных приложений рекомендуется использовать сертифицированные Sun сервера приложений имеющие значок «Java compatible Enterprise Edition».
Криптопро java csp и криптопро jcp в чем отличие
КриптоПро J ava C S P представляет собой Java модуль который выполняет все криптографические операции используя КриптоПро CSP. Данный криптопровайдер сочетает в себе высокую скорость нативного кода с удобством разработки и использования JCE интерфейсов в Java приложениях.
Реализация API КриптоПро J ava C S P совместима с API КриптоПро JCP 2.0. Для работы КриптоПро Java CSP требуется установить криптопровайдер КриптоПро CSP версии 5.0.
КриптоПро Java CSP предназначен для:
Алгоритм выработки значения хэш-функции реализован в соответствии с требованиями ГОСТ Р 34.11 94 «Информационная технология. Криптографическая защита информации. Функция хэширования» и ГОСТ Р 34.11 2012 «Информационная технология. Криптографическая защита информации. Функция хэширования».
Алгоритмы формирования и проверки ЭЦП реализованы в соответствии с требованиями:
ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»;
ГОСТ Р 34.10-2012 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».
Алгоритм зашифрования/расшифрования данных и вычисление имитовставки реализованы в соответствии с требованиями ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая» и ГОСТ 34.12-2015 «Информационная технология. Криптографическая защита информации».
При генерации закрытых и открытых ключей обеспечена возможность генерации с различными параметрами в соответствии с ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012.
При выработке значения хэш-функции и шифровании обеспечена возможность использования различных узлов замены в соответствии с ГОСТ Р 34.11-94/ГОСТ Р 34.11-2012 и ГОСТ 28147-89.
Провайдер Java CSP RSA (требует установки компонента провайдера КриптоПро CSP 5.0 с реализацией иностранных алгоритмов: Crypto-Pro Enhanced RSA and AES CSP) также поддерживает зарубежные алгоритмы: SHA-1, SHA-2, AES (128/192/256), 3DES, 3DES-112, DES, RSA.
КриптоПро Java CSP разработан в соответствии с требованиями интерфейса JCA и может быть использован в операционных системах с установленной виртуальной машиной Java версии 7 и выше или Google Android (версии 7.0 и выше).
Поддерживаемые операционные системы:
В соответствии с КриптоПро JCP, КриптоПро Java CSP функционирует в следующем окружении:
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2001):
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2012, 256 бит):
Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2012, 512 бит):
Длина ключей, используемых при шифровании:
Криптографическая архитектура Java 7 и выше
Стандартные спецификации Java 7 предоставляют стройную систему криптографической защиты информации (ПКЗИ). Более подробно эта архитектура развёрнута по следующим ссылкам:
Отличие криптопро csp от jcp
В ваших реализациях есть ещё одна неточность которая влияет на совместимость между CSP и JCP, а именно:
в реализации CSP есть возможность делать хеш алгоритмом GOST3410DH
а в реализации JCP такая возможность отсутствует, кроме GOST3411 ничего и нет!
Обратите пожалуйста ваше внимание на это,
причем вопрос подобный уже поднимался в 2006 году,
прошло уже два года — а воз и ныне там.
Рашшен маркетинк у вас на высоте.
Статус: Активный участник
Поблагодарили: 3 раз в 3 постах
Если бы вы внимательно читали документы, то знали бы, что алгоритм хеширования только ГОСТ Р 34.11-94
Если бы вы видели разницу между PROV_GOST_2001_DH и GOST_DIGEST_NAME то знали бы в чем разница JCP и CSP
Группы: Администраторы, Участники
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 199 раз в 155 постах
Оль, Серёжа очень умный, сразу видно, что ему ничья помощь не нужна. Он здесь только для того, чтобы поделиться своим богатым опытом.
P.S. PROV_GOST_2001_DH — это тип провайдера, реализующего целый набор криптографических алгоритмов. GOST_DIGEST_NAME — это имя алгоритма хеширования. С такой кашей в голове встречную работу провайдеров вам никогда не организовать.
P.P.S. Без нас в этой теме вы едва ли разберётесь, так что лучше задавайте вопросы и читайте документацию, а не пишите всякие глупости, думая, что кого-то здесь разоблачили.
Гы, я как раз то и читаю документацию и задаю вам вопросы, когда мне в ответ присылают код на Java прежде чем который я буду использовать мне нужно выполнить csptest.exe или что то в этом же духе, уже становится весело. Причем несовместимость CSP и JCP возникает не только у меня. Иначе как объяснить, что на CSP подпись проверку проходит нормально а тот же код на JCP не проходит проверку подписи — с алгоритмами у вас беда, а так же беда с желанием работать.
Группы: Администраторы, Участники
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 199 раз в 155 постах
Объяснить это очень легко: вы делаете ошибки, как при работе с документацией, так и при написании и оформлении простейших программ. Именно поэтому вам говорят запускать csptest, чтобы по крайней мере половина работы была сделана без ошибок. В соседнем топике мы уже выяснили, что никакой несовместимости между нашими продуктами нет.
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important rmation: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close
JCP и Java CSP
Сказал(а) «Спасибо»: 2 раз
Есть Java сервер (ОС Windows) и приложение на Java, необходимо реализовать:
2. Проверка подписи
5. Извлечение информации из сертификатов (хеш и т.д.)
Как я понимаю, для этих целей подойдет библиотека JCP. Но также я обнаружил, что есть продукт Java CSP, который требует:
1. Предустановленный провайдер КриптоПро JCP версии 2.0
2. Предустановленный провайдер КриптоПро CSP 4.0
В чем разница между JCP и Java CSP? Зачем вообще нужен Java CSP, если библиотека JCP сама по себе реализует все необходимые функции без дополнительных компонентов, а для Java CSP необходимы зависимости в виде КриптоПро JCP 2.0 и КриптоПро CSP?
Прежде чем покупать лицензию хочется определиться, какой именно продукт нужен.
Вопрос по версиям: если у нас Java 1.4.2 (VM 4.1), то, получается, что JCP 2.0 и Java CSP несовместимы с нашей Java?
Отсюда возникает вопрос: может ли Java напрямую работать с КриптоПро CSP 4.0 через JCA/JCE, чтобы без установки JCP/Java CSP можно было использовать функции криптопровайдера? Хочется на старой Java получить алгоритмы 2012.
Заранее большое спасибо.
Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 594 раз в 564 постах
JCP содержит криптографические алгоритмы, реализованные на java, а Java CSP (JCSP) — переадресует вызовы в Крипто-Про CSP (использует CryptoAPI). JCSP требует лицензию в том случае, если в Крипто-Про CSP введена серверная лицензия. JCSP может пригодиться в случае работы с более широким списком считывателей, чем есть в JCP, или чтобы использовать гамму (генерировать ключи без БиоДСЧ), или для работы к HSM. Для java версии ниже 1.6 сборок, к сожалению, нет (jcp 1.0.54 без ГОСТ 2012 работает с 1.6). Как вариант, 1) сделать «обертку» над CryptoAPI и вызывать его из java-кода или реализовать вызовы не ко всему CryptoAPI, а тем функциям, которые предполагается использовать в коде, 2) использовать JNA и обращаться к crypt32 и др. из java-кода напрямую (зависит от ОС).
Сказал(а) «Спасибо»: 2 раз
По версиям на сайте указано, что
требуется Java 2 Run Environment версии 1.4.2, 1.5.0 для версии JCP 1.0.46
т.е. на нашей Java какая-то старая сборка JCP 1 все-таки будет работать, но нас это не спасет, т.к. алгоритмы 2012 доступны только в JCP 2, если я верно понял.
Насчет способов решения — вы имеете в виду, что в обоих случаях придется реализовать «нативный» код с использованием wincrypt.h + crypt32.dll + Crypto PRO CSP 4.0?
В первом случае сделать, например, http-сервер на локальном адресе и из джавы обращаться по REST, а во втором случае — мост «управляемый» — «нативный» код. Верно ли я понял?
Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 594 раз в 564 постах
Я имел в виду либо сделать библиотеку с удобными для вас JNI интерфейсами (обращающимися к CryptoAPI) и вызывать из java кода, либо звать CryptoAPI напрямую в java коде (используя JNA) из библиотек, реализующих CryptoAPI. Ваши варианты тоже подходят, но в итоге потребуется обращаться к CryptoAPI.
Версия 1.0.46 устарела и не поддерживается, и, например, ГОСТа 2012 в ней нет.
Сказал(а) «Спасибо»: 2 раз
Евгений, спасибо большое!
Будем думать над предложенными вариантами, другого способа нет…
Статус: Активный участник
Сказал(а) «Спасибо»: 5 раз
Поблагодарили: 1 раз в 1 постах
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important rmation: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close
Использование JCP и CSP
Статус: Активный участник
Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
Рассматриваю каталог дистрибутив для установки JCP+JTLS 2.0. Есть интересный файл JCSP.jar Нутром понимаю, что это самостоятельный криптографический провайдер для Java, когда на машине предустановлен КриптоПро CSP.
Вызывает интерес несколько моментов.
1) На странице https://www.cryptopro.ru/order/ есть лицензия для JCP но нет лицензии для JCSP. Как-то странно, приобретать две лицензии на JCP и CSP. В плане — дороговато за комбайн.
2) Приобретая лицензию на JCP, зачем тогда вообще нужен JCSP?
3) Работает ли связка JTLS + JCSP или в JCSP реализован собственный TLS мост Java + CSP-TLS?
Поймите правильно, на Java разрабатывается не только сервера, но и клиентские приложения. И им надо взаимодействовать с серверами через ГОСТ TLS. Лицензия JTLS подразумевает только сервер.
Клиенты начинают всё больше интересоваться, а заработает ли Java клиент под Linux системами.
Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 594 раз в 564 постах
1) На странице https://www.cryptopro.ru/order/ есть лицензия для JCP но нет лицензии для JCSP. Как-то странно, приобретать две лицензии на JCP и CSP. В плане — дороговато за комбайн.
2) Приобретая лицензию на JCP, зачем тогда вообще нужен JCSP?
3) Работает ли связка JTLS + JCSP или в JCSP реализован собственный TLS мост Java + CSP-TLS?
Поймите правильно, на Java разрабатывается не только сервера, но и клиентские приложения. И им надо взаимодействовать с серверами через ГОСТ TLS. Лицензия JTLS подразумевает только сервер.
Клиенты начинают всё больше интересоваться, а заработает ли Java клиент под Linux системами.
1) Про Java CSP информация находится в https://www.cryptopro.ru…8-e411-8fac-0025900a9c55
2) Приобретается лицензия либо на JCP, либо на JCSP. При этом есть нюансы: JCSP требует лицензию для себя в том случае, если установленный CSP имеет серверную лицензию. Если у CSP лицензия клиентская, то JCSP в лицензии не нуждается. В отношении JTLS так: если создается только клиентское соединение, то для JTLS лицензия не нужна. Если создается серверное (томкат и т.п.), то для JTLS нужна серверная лицензия, а она требует серверную лицензию JCSP и серверную лицензию CSP.
3) Да, работает, т.е. JCSP может заменить JCP. Например, томкат можно так настроить.
Отредактировано пользователем 10 июля 2015 г. 14:53:43(UTC) | Причина: Не указана
1 пользователь поблагодарил Евгений Афанасьев за этот пост.
Сказала «Спасибо»: 1 раз
При этом есть нюансы: JCSP требует лицензию для себя в том случае, если установленный CSP имеет серверную лицензию. Если у CSP лицензия клиентская, то JCSP в лицензии не нуждается.
Добрый день! Из ответа я не поняла, для серверного соединения нужно покупать лицензию CSP и JSCP? Т.е. CSP + JCSP работают в связке, аналогично JCP + JTLS? Уточните, пожалуйста.
Отредактировано пользователем 29 октября 2015 г. 12:35:41(UTC) | Причина: Не указана
Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 594 раз в 564 постах
для серверного соединения нужно покупать лицензию CSP и JSCP? Т.е. CSP + JCSP работают в связке, аналогично JCP + JTLS? Уточните, пожалуйста.
При создании серверного соединения с помощью JTLS будет произведена проверка лицензии JCP на серверность, если использует только он, или JCSP и CSP, если используется JCSP в качестве провайдера.
Сказала «Спасибо»: 1 раз
Добрый день! Я видимо запуталась в продуктах и никак не могу понять принцип лицензирования. Объясните мне, пожалуйста, в чем заключается отличие между СКЗИ «КриптоПро JavaCSP» (https://www.cryptopro.ru/products/csp/jcp/jtls) и СКЗИ «КриптоПро JCP» (https://www.cryptopro.ru/products/csp/jcp)? Сейчас мы для организации серверного соединения используем СКЗИ «КриптоПро JCP» и КриптоПро JavaTLS. Правильно ли я понимаю из темы, что связку, используемую для организации серверного соединения (КриптоПро JCP + КриптоПро JavaTLS), можно заменить на КриптоПро JavaCSP, при этом дополнительно больше ставить ничего не нужно?
Буду признательна, если поможете разобраться.
Отредактировано пользователем 30 октября 2015 г. 11:01:57(UTC) | Причина: Не указана
Группы: Администраторы, Участники
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 172 раз в 151 постах
Нет. Для организации TLS на серверы вам нужно или
1) КриптоПро JCP + КриптоПро JTLS
2) КриптоПро JCSP + КриптоПро JTLS + КриптоПро CSP (именно в этом продукте будет основная выполнятся основная работа).
JCSP — представляет собой просто интерфейс на JAVA к криптопровайдеру КриптоПро CSP.
Сказала «Спасибо»: 1 раз
Нет. Для организации TLS на серверы вам нужно или
1) КриптоПро JCP + КриптоПро JTLS
2) КриптоПро JCSP + КриптоПро JTLS + КриптоПро CSP (именно в этом продукте будет основная выполнятся основная работа).
JCSP — представляет собой просто интерфейс на JAVA к криптопровайдеру КриптоПро CSP.
Спасибо! Теперь все стало на свои места. Я так понимаю продукта JCSP функционал схож с функционалом TrustedTLS.
Хотела уточнить еще один момент, для связки КриптоПро JCP + КриптоПро JTLS это применимо:
если создается только клиентское соединение, то для JTLS лицензия не нужна. Если создается серверное (томкат и т.п.), то для JTLS нужна серверная лицензия
Отредактировано пользователем 30 октября 2015 г. 11:37:33(UTC) | Причина: Не указана
Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 594 раз в 564 постах
Да, если создается клиентское подключение, то лицензия в JTLS не проверяется (не нужна).
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important rmation: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close
Как на Java c помощью КриптоПро подписать документ PDF
Привет! Я сотрудник Альфа-Банка и занимаюсь разработкой программного обеспечения со встроенными средствами криптографической защиты информации.
В данной статье хочу рассказать о следующих вещах:
В современном информационном мире значимость электронной подписи и предоставляемых ею основных сервисов (целостность данных, и неотрекаемость авторства) сложно переоценить. Государственные органы, физические и юридические лица широко применяют электронную подпись в потоках обмена информацией между собой.
Согласно законодательству, электронная подпись может придать документам юридическую силу, равную по значимости бумажному носителю, подписанному собственноручной подписью и скрепленного печатью правомочного лица.
Преимущества PDF
В качестве контейнера для хранения разнообразной информации в дружественном для человека представлении формат PDF по праву завоевал свою популярность. Его получится открыть в любой ОС. Документ PDF может содержать не только текстовые и табличные данные, но и аудио и видеозаписи, инженерную графику, трехмерные модели. Для дополнительной обработки PDF-документов в данный формат включен такой мощный инструмент как поддержка JavaScript для изменения содержимого в формах и полях по наступлению какого-то события или выполнению действия пользователя.
Инструменты Adobe Systems (разработчика формата PDF) поддерживают использование электронной подписи. В отличие от сообщений с присоединенной усиленной электронной подписью стандарта PKCS#7 и его усовершенствования CAdES, для просмотра документа PDF с подписью не требуется дополнительное специальное ПО. Кроме криптографического провайдера, который требуется во всех случаях.
Т.е. инструменты Adobe позволяют визуализировать электронную подпись в документе.
При подписании документа PDF можно задать параметры визуализации, указать номер страницы, размер блока с подписью, имя поля, куда ее поместить, добавить графическое изображение, например, логотип компании, скан собственноручной подписи руководителя и печати организации.
При просмотре таких документов, кроме визуализации в теле документа, программы Acrobat и Adobe Reader отображают вкладку «Подписи» с сопутствующей информацией: значок, показывающий статус проверки подписи, сведения о том, был ли изменен документ, результат проверки сертификата открытого ключа, время последней проверки, страницу и поле, содержащие электронную подпись.
Инструменты подписи
Использовалась версия Java: «1.8.0_111» HotSpot(TM) 64-Bit Server VM (build 25.111-b14).
В качестве сертифицированного средства защиты информации от лицензированного разработчика применяем криптографический провайдер КриптоПро CSP v4.0 и КриптоПро JCP — v.2.0, с установкой модуля КриптоПро Java CSP v.4.0
Почему КриптоПро JCP — v.2.0, с модулем КриптоПро Java CSP v.4.0?
Потому, что провайдер КриптоПро JCP после длительного несертифицированного периода получил сертификат соответствия от регулятора до 31.12.2018, а дальше, по информации от разработчика, с сертификацией может вновь возникнуть неопределенность. Модуль КриптоПро Java CSP v.4.0 не выполняет в себе криптографических преобразований и является по сути API к провайдеру КриптоПро CSP, с очередной сертификацией которого вопросов нет. Здесь нужно сказать, что действующий сертификат на СКЗИ не обязателен при условии использования криптографического провайдера исключительно для внутренних целей.
# List of providers and their preference orders (see above):
Не забываем, что должны быть сняты экспортные ограничения платформы Java, которые блокируют работу криптографических провайдеров с российскими алгоритмами шифрования.
и содержащие в default_local.policy и default_US_export.policy:
// There is no restriction to any algorithms.
Применение библиотеки iText itextpdf.com для работы с PDF документами на Java было продиктовано провайдером КриптоПро.
В составе КриптоПро JCP поставляется файл Git patch для библиотеки iTextpdf версии 5.1.3 —
Патч адаптирует itextpdf к работе с провайдером КриптоПро. Необходимо скачать исходный код библиотеки версии 5.1.3, затем с помощью командной строки Bash системы управления версиями Git применить патч: git apply — itextpdf_5.1.3.gost.user.patch
Далее нужно собрать полученную библиотеку из обновленного исходного кода и подключить к приложению.
В составе КриптоПро JCP можно найти много примеров в файле samples-sources.jar. В частности, там есть примеры подписи и проверки ЭП PDF-документов. (PDFVerifyPDFExample.java).
Проблемы и трудности сборки
После успешного обновления исходного кода itextpdf в нем появляются зависимости на пакеты ru.CryptoPro.JCP и ru.CryptoPro.reprov.x509.
Без них проект с исходным кодом itextpdf_5.1.3.gost не соберется.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project itextpdf: Compilation failure: Compilation failure:
[ERROR] githubiTextpdf_5.1.3_patched_cryptopro_bc1.50srcmainjavacomitextpdftextpdfPdfPKCS7.java:[138,23] error: package ru.CryptoPro.JCP does not exist
[ERROR] githubiTextpdf_5.1.3_patched_cryptopro_bc1.50srcmainjavacomitextpdftextpdfPdfPKCS7.java:[139,31] error: package ru.CryptoPro.reprov.x509 does not exist
Нужно взять из поставки КриптоПро 2.0 файлы JCP.jar и JCPRevTools.jar и поместить в каталог JRE, которую использует Maven: Javajdk1.8.0_111jrelibext. Само собой, они должны быть и в classPath приложения.
Итак, библиотека собрана, подключаем ее в приложение. И тут возникает основная проблема. iTextpdf_5.1.3 содержит зависимость на Bouncy Castle версии 1.46 — библиотеку с открытым кодом, реализующую криптографический провайдер и поддержку ASN.1 структур.
Поставка КриптоПро JCP 2.0 в свою очередь имеет зависимости на Bouncy Castle версии 1.50 bcpkix-jdk15on-1.50 и bcprov-jdk15on-1.5, соответственно, они помещаются в jre/lib/ext при установке КриптоПро.
В итоге при запуске своего приложения и метода подписания PDF мы получаем ошибку:
Exception in thread «main» java.lang.NoClassDefFoundError: org/bouncycastle/asn1/DEREncodable
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.asn1.DEREncodable
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Каждый разработчик Java сталкивался с таким исключением в потоке main и знает, что можно потратить много времени на разбор проблемы, и как все исправить. Суть исключения NoClassDefFoundError следующая — оно выбрасывается, когда виртуальная машина Java во время исполнения приложения не может найти конкретный класс, который был доступен на этапе компиляции.
Что получается — библиотека iTextpdf_5.1.3 имеет зависимость от более старого провайдера Bouncy Castle, а для новых версий iTextpdf нет патча от КриптоПро.
Конкретно в поставке КриптоПро JCP 2.0 зависимости на новую версию Bouncy Castle имеет библиотека CAdES.jar. Если удалить из JRE эту библиотеку или вовсе отказаться от поддержки формирования CAdES подписей при установке КриптоПро JCP 2.0, то проблема будет решена.
Но что если поддержка CAdES должна остаться?
Чтобы избавиться от конфликта библиотек, необходимо предпринять следующие шаги:
Как итог, проект iTextpdf_5.1.3_patched_cryptopro_bc1.50 начинает собираться. Конфликт разрешен, КриптоПро и itextpdf ссылаются на одну версию org.bouncycastle 1.50.
Исходный код iTextpdf_5.1.3_patched_cryptopro_bc1.50 выложен в GitHub: iTextpdf_5.1.3_patched_cryptopro_bc1.50
Пример кода, несколько подписей PDF
Пример использования КриптоПро и iTextpdf_5.1.3_patched_cryptopro_bc1.50 выглядит следующим образом:
Метод принимает на вход список имен контейнеров с ключами электронной подписи, байты PDF-документа и номер версии формата PDF. Согласно указанным именам, ключи и сертификаты извлекаются из кэша. Подгружается изображение для визуализации подписи.
Создается объект с корневым сертификатом для формирования пути сертификации, который требуется методу setCrypto класса com.itextpdf.text.pdf.PdfatureAppearance.
В цикле выполняется подпись страниц PDF-документа ключами, имена которых были переданы в метод.
Для демонстрации выполнены две подписи — валидная и невалидная с недействительным сертификатом.
Вкладка «Подписи» выглядит следующим образом:
Применение электронной подписи PDF-документов
На мой взгляд, подпись непосредственно в PDF формате является частным случаем. Такой штамп в самом файле предназначен скорее для визуализации ЭП с целью проверки ее глазами. Это удобно и эффектно, когда речь идет о небольшом количестве документов, где не требуется автоматизация, а роль проверяющего выполняет оператор.
С интенсивным процессом обмена большим количеством электронных документов, оператор не справится. В этом случае информационная система выполняет автоматизацию, и необходимость в красивой визуализации отпадает. Соответственно излишне тратить ресурсы информационной системы и электронных каналов, на передачу объемных PDF файлов и обработку изображений штампа.
Практичнее формировать электронную подпись в виде отдельного файла или оборачивать файл и подпись в один контейнер стандарта PKCS#7 (CAdES). Этот стандарт с присоединенной или отсоединенной подписью отлично подойдет для большого документооборота между информационными системами.
Тот же документ PDF можно подписать по стандарту CAdES отсоединенной подписью, в итоге будет два файла — сам PDF и контейнер с подписью.
Вспомним проблемы, с которыми пришлось столкнуться при подписании на Java. Вывод — формат PDF сейчас плохо поддерживается КриптоПро в части прикладного программного интерфейса для Java. Существующую библиотеку itextpdf пришлось править самостоятельно.
В сфере деятельности, связанной с разработкой коммерческого программного обеспечения со встроенными СКЗИ, такой подход недопустим, патчи, обновления и доработки должны выполняться организацией-лицензиатом. Поэтому приведенный в посте способ подписи PDF-документа можно применять с целью демонстрации возможностей и для внутреннего использования.