Программные интерфейсы¶

Новинки версии¶

В сборке r507 доработано чтение сертификатов из хранилища. Ранее не возвращались сертификаты с алгоритмом публичного ключа ГОСТ 2012 (256 - 512). Использование:

CryptoProCSPCertStore storeCsp = new CryptoProCSPCertStore();
Collection certificates = storeCsp.getInstance("CurrentUser/ROOT",
null).getAllCertificates();

В сборке r506 добавлена возможность проверки подписи с отключением/включением сортировки подписанных атрибутов (по умолчанию они не сортируются. Использование:

SignerInformation si;
...
si.setNeedSortSignedAttributes(true);
si.verify(cert, PROV_NAME))

В сборке r505 добавлена поддержка алгоритмов ГОСТ 2012 для XML.

В версии Trusted Java 2.0 (сборка r504 и выше) добавлена поддержка работы с ключами и алгоритмами ГОСТ Р 34.11-2012/ГОСТ Р 34.10-2012 (только с КриптоПро CSP 4.0).

В версии Trusted Java 2.0 изменилась система лицензирования. Теперь полученный лицензионный ключ действителен только для одной платформы ОС и не подходит к другой. Поэтому следует пользователям, переходящим на новую версию, обновить или приобрести под другую платформу лицензионные ключи.

В версии Trusted Java 2.0 обеспечена обратная совместимость с продуктом КриптоАРМ в плане создания и проверки ЭЦП и шифрования данных. Это, в частности, достигнуто за счет адаптации JCE провайдера для использования его в связке с библиотеками от BounceCastle: оригинальной библиотеки JCEпровайдера bcprov-jdk15-145.jar и пропатченной bcmail-библиотеки bcmailjdk15-145-tj20-rbbb.jar, ссылки на которые можно получить в центре загрузки. В результате появилась возможность создавать и проверять заверяющие подписи.

В версии Trusted Java 2.0 улучшена работа с SSL-сокетами, усовершенствованы механизмы аутентификации сервера и клиента, реализована поддержка шифросюиты (CipherSuite) 0x81 (TLS_GOSTR341001_WITH_28147_CNT_IMIT).

Версия Trusted Java 1.5.3 поддерживает работу с КриптоПро CSP 3.6.

Версия Trusted Java 1.5.2 включает в себя как совершенно новые, так и оптимизированные по сравнению с более ранними версиями, функциональные возможности:

• обеспечена совместимость JSSE с веб-сервером Apache Tomcat 5.5;

• добавлены новые классы для обеспечения совместимости XMLSig с MS XML;

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

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

Объекты управления¶

JCE и ее особенности¶

JCE создает структуру и реализацию шифрования, образования ключей и их согласования, а также алгоритмов аутентификации сообщений (MAC). Шифрование базируется на использовании симметричных, асимметричных, блочных и поточных шрифтов.

Программное обеспечение также поддерживает передачу защищенных потоков и закрытых объектов.

JCE основана на тех же структурных принципах, что и другие программы JCA: независимость реализаций и, если это возможно, независимость алгоритмов.

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

Программный интерфейс JCE включает¶

• Симметричное групповое шифрование, например, DES, RC 2, илиIDEA;

• Симметричное поточное шифрование, например, RC 4;

• Асимметричное шифрование, например, RSA;

• Шифрование с использованием пароля ( PBE);

• Согласование ключей;

• Коды аутентификации сообщений (MAC).

Стандартный выпуск программы JAVA 2 SDK, версия 1.5 поставляется с предварительно установленным и зарегистрированным провайдером JCE « SunJCE », который предоставляет следующие криптографические функции:

Использование алгоритмов шифрования

• DES (FIPS PUB 46-1);

• Triple DES и Blowfish в режимах ECB (электронная кодовая книга);

• CBC (сцепление кодовых блоков);

• CFB (программируемый функциональный блок);

• OFB (обратная связь по выходу);

• PCBC (сцепление распространенных кодовых блоков).

• Генераторы ключей, используемые для образования ключей, подходящих для алгоритмов стандартов DES, Triple DES, Blowfish, HMAC-MD5 и HMAC-SHA1;

• Использование стандарта MD5 с алгоритмом шифрования с использованием паролей DES-CBC, определенным в стандарте PKCS #5;

• «Фабрики закрытых ключей», обеспечивающие двусторонний переход между зашифрованными объектами ключей DES, Triple DES и PBE и прозрачными представлениями их базового ключевого материала;

• Реализация алгоритма согласования кодов Diffie-Hellman между двумя или более частями;

• Парный генератор кодов Diffie-Hellman для составления общих и частных значений, используемых в алгоритме Diffie-Hellman;

• Параметрический генератор алгоритма Diffie-Hellman;

• «Фабрика ключей» Diffie-Hellman, обеспечивающая двусторонние переходы между зашифрованными ключевыми объектами DiffieHellman и прозрачными представлениями их базового ключевого материала;

• Параметрические диспетчеры алгоритмов для параметров стандартов Diffie-Hellman, DES, Triple DES, Blowfish и PBE;

• Использование алгоритмов хэширования кодов HMAC-MD5 и HMACSHA1, определенных в стандарте RFC 2104;

• Использование схемы дополнения данными, описанной в стандарте PKCS #5;

• Использование собственной реализации ключевого хранилища «JCEKS».

Подробное описание программы JCE представлено на сайте компании Sun

Настройка JSSE¶

Процедура настройки JSSE проходит в 3 этапа:

• ознакомление с общими требованиями

• интеграция с Internet Explorer

• двусторонняя аутентификация

Общие требования¶

Полнофункциональная работа с Java апплетами по протоколу GOST TLS c помощью Digt JSSE возможна лишь на платформе win32 с использованием MS Internet Explorer 5 и более поздних версий. В системе должен быть установлен CryptoPro CSP версии 3.6 или 4.0, а также Sun JRE и Java плагин для IE.

Реализация ГОСТ TLS в рамках Java JSSE API с помощью подмены SocketFactory возможна лишь для версий Java 1.5 (и выше) из-за экспортных ограничений, существовавших в предыдущих версиях.

Последовательность действий при интеграции с IE 1) Cкопировать библиотеку trusted_java20.jar в каталог $path_to_jre/lib/ext 2) Указать, что при создании SSL соединений должен использоваться DigtSocketFactory класс в файле настроек безопасности \lib\security\java.security

#
# Determines the default SSLSocketFactory and SSLServerSocketFactory
# provider implementations for the javax.net.ssl package. If, due to
# export and/or import regulations, the providers are not allowed to be
# replaced, changing these values will produce non-functional
# SocketFactory or ServerSocketFactory implementations.
#
ssl.SocketFactory.provider=com.digt.trusted.jsse.provider.DigtSocketFactory
#ssl.ServerSocketFactory.provider=

Двусторонняя аутентификация¶

Работа с клиентскими сертификатами в Digt JSSE отличается от стандартных способов задания параметров KeyStore в JSSE API в связи с тем, что CryptoPro CSP использует собственный формат хранилища сертификатов и ключевых контейнеров, который не может быть представлен в виде файла.

Для организации защищенных ГОСТ TLS соединений с использованием двусторонней аутентификации Digt JSSE провайдер использует для задания сертификата следующие параметры из системного окружения Java VM, которые могут быть заданы либо с командной строки, используя ключ запуска –D, либо установлены программно с помощью метода System.setProperty():

пример задания из командной строки

java –Dcom.digt.trusted.jsse.certFile=file.cer –D com.digt.trusted.jsse.keyPasswd=

пример задания из программы на Java

System.setProperty("com.digt.trusted.jsse.certFile", "file.cer");
System.setProperty("com.digt.trusted.jsse.keyPasswd", "").

Параметр com.digt.trusted.jsse.certFile указывает путь к файлу с сертификатом, который должен содержать данные сертификата в формате base64. Параметр com.digt.trusted.jsse.keyPasswd содержит необязательный пин-код для ключевого контейнера CryptoPro CSP, который соответствует данному сертификату.

Примеры: Иллюстрацией работы JSSE клиента может служить тестовый класс SSLSocketClient.java из архива примеров, поставляемых с дистрибутивом. Внимание! В данной версии библиотеки существует ограничение, в рамках которого параметры сертификата задаются однократно перед инициализацией провайдера, и их последующее изменение в контексте текущего приложения невозможно без полной выгрузки классов провайдера.

Общая информация¶

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

• создание сертификатов x509;

• формирование запроса на сертификат;

• установка сертификата в хранилище;

• проверка подписи по сертификату;

• работа со списками отозванных сертификатов;

• поддержка CMS;

• поддержка OCSP (проверка статуса сертификата в on-line);

• поддержка TSP (работа со Службой штампов времени).

Trusted Java реализуется в виде JCE провайдера, предоставляющего работу с криптографическими протоколами по алгоритмам ГОСТ. Основу реализованных алгоритмов ГОСТ в Trusted Java составляют криптореализации КриптоПро CSP.

Продукт поддерживает следующие сертифицированные алгоритмы:

• ГОСТ Р 34.11 – основной класс GOST3411Digest;

• ГОСТ Р 34.11-2012 – основные классы GOST3411v12256Digest и GOST3411v12512Digest;

• ГОСТ Р 34.10-94 – класс генерации ключей GOST3410KeyPairGenerator, класс ЭЦП GOST3410Signer (в связи с тем, что стандарт ГОСТ Р 34.10-94 устарел, данные классы оставлены только для совместимости с предыдущими версиями);

• ГОСТ Р 34.10-2012 - классы генерации ключей GOST3410v12256KeyPairGenerator и GOST3410v12512KeyPairGenerator, классы ЭЦП GOST3410v12256Signer и GOST3410v12512Signer

• ГОСТ Р 34.10-2001 – класс генерации ключей GOST3410ELKeyPairGenerator, класс ЭЦП GOST3410 EL Signer.

• ГОСТ 28147-89 - основной класс GOST28147Engine;

Наряду с этим, добавлен алгоритм Diffie-Hellman. Разработанные классы наиболее приближены к реализациям классов в JCE.

Сами реализации криптографических алгоритмов в классах GOST отсутствуют. В методах классов вызываются функции из библиотеки с реализациями ГОСТ алгоритмов КриптоПро CSP.

Классы, относящиеся к ГОСТ Р.3410-94, имеют в составе имени GOST3410, классы, относящиеся к ГОСТ Р.3410-2001, – GOST3410EL, классы, относящиеся к ГОСТ Р.3410-2012 – GOST3410v12<256/512>. Помимо этого, некоторые классы (GOST3410EL и GOSTDH) в силу идентичности общих начальных классов ключей и схожей структуры используют одни общие классы с именами GOST3410 (GOSTDH заимствует имена GOST3410, GOSTECDH заимствует имена GOST3410EL).

Строковыми параметрами ключей в GOST являются соответствующие OID.

Отличными от классов той же функциональной группы являются классы GOSTDHAgreement, JDKGOSTKeyStore.

В GOSTDHAgreement при импорте и экспорте сессионный ключ передается шифрованным на общем ключе обмена участников (с дополнительными параметрами для восстановления (дефолтные iv, режим, заполнитель)).

В целях соблюдения совместимости интерфейсов JCE некоторые методы и передаваемые параметры в ГОСТ классах не используются. Подробности даны в примерах и описаниях классов.

Некоторые общие методы¶

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

Вызов этого метода происходит непосредственно вручную или же уничтожение не использующихся контекстов происходит при выгрузке djcpбиблиотеки из памяти (в случае, если не использован метод destroy).

Метод public void destroy() вставлен для уничтожения контекстов, создававшихся при работе объекта с библиотекой. Данный метод применяется при необходимости уничтожить контексты до завершения программы.