Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Архитектура Криптографии Java
Документация Провайдеров Oracle

для Платформы Java Standard Edition 7

Отметьте: Документация Стандартных имен содержит больше информации о стандартных именах, используемых в этом документе.

Введение

Платформа Java определяет ряд API, охватывающих главные области безопасности, включая криптографию, инфраструктуру управления открытыми ключами, аутентификацию, безопасную передачу, и управление доступом. Эти API позволяют разработчикам легко интегрировать механизмы безопасности в свой код программы. Архитектура Криптографии Java (JCA) и его Архитектура Провайдера являются базовым понятием Комплекта разработчика для Java (JDK). Это - принятые читатели, имеют основательное понимание этой архитектуры.

Этот документ описывает технические детали провайдеров, поставленных как часть Среды Java Oracle.

Напоминание: Криптографические реализации в JDK распределяются через несколько различных провайдеров ("Sun", "SunJSSE", "SunJCE", "SunRsaSign") и по историческим причинам и типами предоставленных услуг. Приложения общего назначения не ДОЛЖНЫ запросить криптографические службы от определенных провайдеров. Это:

    getInstance("...", "SunJCE");  // not recommended
        vs.
    getInstance("...");            // recommended

Иначе, приложения связываются к определенным провайдерам, которые, возможно, не доступны на других реализациях Java. Они также не могли бы быть в состоянии использовать в своих интересах доступных оптимизированных провайдеров (например, аппаратные акселераторы через PKCS11 или собственные реализации ОС, такие как MSCAPI Microsoft), у которых есть более высокий привилегированный порядок чем определенный требуемый провайдер.

Пределы импорта на Криптографических алгоритмах

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

Если более сильные алгоритмы необходимы (например, AES с 256-разрядными ключами), Неограниченные Файлы Политики Юрисдикции Силы JCE должны быть получены и установлены в JDK/JRE.

Это - обязанность пользователя проверить, что это действие допустимо в соответствии с местными постановлениями.

SunPKCS11 Провайдер

Криптографический Маркерный Стандарт Интерфейса (PKCS#11) обеспечивает собственные интерфейсы программирования для криптографических механизмов, таких как аппаратные средства криптографические акселераторы и Смарт-карты. Когда должным образом конфигурирующийся, SunPKCS11 провайдер позволяет приложениям использовать стандартные API JCA/JCE, чтобы получить доступ собственный PKCS#11 библиотеки. SunPKCS11 сам провайдер не содержит криптографическую функциональность, это - просто кабелепровод между средой Java и собственными провайдерами PKCS11. У Java PKCS#11 Справочник есть намного более подробная обработка этого провайдера.

SUN Провайдер

JDK 1.1 представлял Provider архитектура. Первого провайдера JDK назвали SUN, и содержавший два типа криптографических служб (MessageDigests и Signatures). В более поздних выпусках были добавлены другие механизмы (SecureRandom генераторы чисел, KeyPairGenerators, KeyFactorys, и так далее.).

Инструкции экспорта Соединенных Штатов в действительности в это время установленные существенные ограничения для типа криптографической функциональности, которая могла быть сделана доступной на международном уровне в JDK. Поэтому SUN провайдер исторически содержал криптографические механизмы, которые непосредственно не шифровали или дешифровали данные.

Следующие алгоритмы доступны в SUN провайдер:

Ограничения размера ключа

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

KeyPairGenerator

AlgorithmParameterGenerator

CertificateFactory/CertPathBuilder/ CertPathValidator/CertStore Реализации

Дополнительные детали о SUN реализации провайдера для CertificateFactory, CertPathBuilder, CertPathValidator и CertStore документируются в Приложение B Руководства Программиста PKI.

SunRsaSign Провайдер

SunRsaSign провайдер был представлен в JDK 1.3 как улучшенная замена для подписей RSA в SunJSSE провайдер.

Следующие алгоритмы доступны в SunRsaSign провайдер:

Ограничения размера ключа

SunRsaSign провайдер использует следующий размер ключа по умолчанию (в битах) и осуществляет следующее ограничение:

KeyPairGenerator

SunJSSE Провайдер

Расширение Защищенного сокета Java (JSSE) было первоначально выпущено как отдельный "Дополнительный Пакет" (также кратко известный как "Стандартное Расширение"), и было доступно для JDK 1.2.n и 1.3.n. SunJSSE провайдер был представлен как часть этого выпуска.

В более ранних выпусках JDK не было никаких провайдеров подписи RSA, доступных в JDK, поэтому SunJSSE должен был обеспечить его собственную реализацию RSA, чтобы использовать обычно доступные RSA-на-основе сертификаты. JDK 5 представлял SunRsaSign провайдер, который обеспечивает всю функциональность (и больше) SunJSSE провайдер. Приложения, предназначенные в JDK 5.0 и позже, должны запросить экземпляры SunRsaSign провайдер вместо этого. Для обратной совместимости алгоритмы RSA все еще доступны через этого провайдера, но фактически реализуются в SunRsaSign провайдер.

Алгоритмы

Следующие алгоритмы доступны в SunJSSE провайдер:

Протоколы

SunJSSE поддерживает следующий protocol параметры:

Хотя SunJSSE в Java SE 7 выпусков поддерживают TLS 1.1 и TLS 1.2, никакая версия не включается по умолчанию для клиентских соединений. Некоторые серверы не реализуют прямую совместимость правильно и отказываются говорить с TLS 1.1 или TLS 1.2 клиента. Для функциональной совместимости, SunJSSE не включает TLS 1.1 или TLS 1.2 по умолчанию для клиентских соединений.

У соединений сервера нет такой проблемы функциональной совместимости. TLS 1.1 и TLS 1.2 включаются по умолчанию для соединений сервера.

SSLv3, TLSv1, и протоколы TLSv1.1 позволяют Вам отправлять SSLv3, TLSv1, и TLSv1.1 hellos инкапсулировавший в формате SSLv2 привет. В Java SE 7 выпусков эта поддержка все еще присутствует, но отключается по умолчанию.

Комплекты шифра

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

Первая таблица приводит комплекты шифра, которые являются включением по умолчанию. Вторая таблица показывает комплекты шифра, которые поддерживаются SunJSSE, но отключаются по умолчанию.

¹ комплект Шифра с SHA384 и SHA256 доступен только для TLS 1.2 или позже.

² TLS_EMPTY_RENEGOTIATION_INFO_SCSV новый комплект псевдошифра, чтобы поддерживать RFC 5746. См. Безопасность Транспортного уровня (TLS) раздел Проблемы Пересмотра Справочника JSEE для получения дополнительной информации.

¹ TLS RFC 5246 1.2 запрещает использование этих комплектов. Они могут использоваться в SSLv3/TLS1.0/TLS1.1 протоколах, но не могут использоваться в TLS 1.2 и позже.

² TLS RFC 4346 1.1 запрещают использование этих комплектов. Они могут использоваться в протоколах SSLv3/TLS1.0, но не могут использоваться в TLS 1.1 и позже.

Комплекты шифра, которые используют AES_256, требуют установки Неограниченных Файлов Политики Юрисдикции Силы JCE. См. Пределы Импорта на Криптографических алгоритмах.

Комплекты шифра, которые используют Шифрование в эллиптических кривых (ECDSA, ECDH, ECDHE, ECDH_anon) требуют криптографического провайдера JCE, который удовлетворяет следующие требования:

• Провайдер должен реализовать ECC как определено классами и интерфейсами в пакетах java.security.spec и java.security.interfaces. getAlgorithm() метод ключевых объектов эллиптической кривой должен возвратить строку "EC".

• Провайдер должен поддерживать Signature алгоритмы SHA1withECDSA и NONEwithECDSA, KeyAgreement алгоритм ECDH, и a KeyPairGenerator и a KeyFactory для алгоритма EC. Если один из этих алгоритмов будет отсутствовать, то SunJSSE не будет позволять комплектам шифра EC использоваться.

• Провайдер должен поддерживать все кривые SECG, на которые ссылаются в спецификации RFC 4492, разделить 5.1.1 (см. также приложение A). В сертификатах точки должны быть закодированы, используя несжатую форму, и кривые должны быть закодированы, используя namedCurve выбор, то есть, используя объектный идентификатор.

Если эти требования не удовлетворяются, комплекты шифра EC не могут быть согласованы правильно.

Более трудная Проверка Номеров версий EncryptedPreMasterSecret

До Java SE 7 выпусков реализация SSL/TLS не проверяла номер версии в PreMasterSecret, и клиент SSL/TLS не отправлял корректный номер версии по умолчанию. Если системное свойство com.sun.net.ssl.rsaPreMasterSecretFix устанавливается в true, клиент TLS отправляет активную согласованную версию, но не ожидаемую максимальную версию, поддерживаемую клиентом.

Для совместимости это поведение сохраняется для версии 3.0 SSL и версии 1.0 TLS. Однако, для версии 1.1 TLS или позже, реализация сжимает проверку номеров версий PreMasterSecret как требуется RFC 5246. Клиенты всегда отправляют корректный номер версии, и серверы проверяют номер версии строго. Системное свойство, com.sun.net.ssl.rsaPreMasterSecretFix, не используется в TLS 1.1 или позже.

SunJCE Провайдер

Как описано кратко в SUN Провайдер, инструкции экспорта US в то время, когда ограничено тип криптографической функциональности, которая могла быть сделана доступной в JDK. Отдельный API и ссылочная реализация были разработаны, который позволил приложениям шифровать/дешифровать данные. Java Криптографическое Расширение (JCE) было выпущено как отдельный "Дополнительный Пакет" (также кратко известный как "Стандартное Расширение"), и было доступно для JDK 1.2.x и 1.3.x. Во время разработки JDK 1.4, инструкции были ослаблены достаточно, что JCE (и SunJSSE) мог быть связан как часть JDK.

Следующие алгоритмы доступны в провайдере SunJCE:

Следующая таблица приводит алгоритмы шифра, доступные в провайдере SunJCE.

¹ PBEWithMD5AndTripleDES является собственным алгоритмом, который не был стандартизирован.

Ограничения размера ключа

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

KeyGenerator

ОТМЕТЬТЕ: различное Основанное на пароле Шифрование (PBE), алгоритмы используют различные алгоритмы, чтобы генерировать ключевые данные, и в конечном счете зависят от предназначенного алгоритма Шифра. Например, "PBEWithMD5AndDES" будет всегда генерировать 56-разрядные ключи.

KeyPairGenerator

AlgorithmParameterGenerator

SunJGSS Провайдер

Следующие алгоритмы доступны в SunJGSS провайдер:

SunSASL Провайдер

Следующие алгоритмы доступны в SunSASL провайдер:

XMLDSig Провайдер

Следующие алгоритмы доступны в XMLDSig провайдер:

SunPCSC Провайдер

Провайдер SunPCSC позволяет приложениям использовать API ввода-вывода Смарт-карты Java, чтобы взаимодействовать со стеком Смарт-карты PC/SC базовой операционной системы. На некоторых операционных системах может быть необходимо включить и сконфигурировать стек PC/SC прежде, чем это будет применимо. Консультируйтесь со своей документацией операционной системы для деталей.

На Солярисе и платформах Linux, SunPCSC получает доступ к стеку PC/SC через libpcsclite.so библиотека. Это ищет эту библиотеку в каталогах /usr/$LIBISA и /usr/local/$LIBISA, где $LIBISA расширяется до lib на 32-разрядных платформах, lib/64 на 64-разрядных платформах Соляриса, и lib64 на 64-разрядных платформах Linux. Системное свойство sun.security.smartcardio.library май также быть установленным в полное имя файла альтернативы libpcsclite.so реализация. На платформах Windows SunPCSC всегда вызывает в winscard.dll и никакая конфигурация на уровне Java не необходима или возможна.

Если PC/SC доступен на платформе узла, реализация SunPCSC может быть получена через TerminalFactory.getDefault() и TerminalFactory.getInstance("PC/SC"). Если PC/SC не доступен или не правильно сконфигурированный, a getInstance() вызов перестанет работать с a NoSuchAlgorithmException и getDefault() возвратит встроенную реализацию JRE, которая не поддерживает терминалов.

Следующие алгоритмы доступны в SunPCSC провайдер:

SunMSCAPI Провайдер

Провайдер SunMSCAPI позволяет приложениям использовать стандартные API JCA/JCE, чтобы получить доступ к собственным криптографическим библиотекам, хранилищам сертификатов и ключевым контейнерам на платформе Microsoft Windows. Провайдер самого SunMSCAPI не содержит криптографическую функциональность, это - просто кабелепровод между средой Java и собственными криптографическими службами на Windows.

Следующие алгоритмы доступны в SunMSCAPI провайдер:

Ограничения размера ключа

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

KeyGenerator

SunEC Провайдер

Провайдер SunEC реализует Эллиптическую Криптографию Кривой (ECC). ECC появляется в качестве привлекательной криптографической системы с открытым ключом для мобильных/беспроводных и других сред. По сравнению с традиционными криптографическими системами как RSA ECC предлагает эквивалентную безопасность с меньшими размерами ключа, которая приводит к более быстрым вычислениям, более низкому расходу энергии, так же как сбережениям пропускной способности и памяти.

Приложения могут теперь использовать стандартные API JCA/JCE, чтобы получить доступ к функциональности ECC без зависимости от внешних библиотек ECC (через SunPKCS11), как имел место в JDK 6 выпусков.

Следующие алгоритмы доступны в SunEC провайдер:

Ограничения размера ключа

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

KeyPairGenerator

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами