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

1. Независимость реализации

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

2. Функциональная совместимость реализации

   Провайдеры являются взаимодействующими через приложения. Определенно, приложение не связывается с определенным провайдером, и провайдер не связывается с определенным приложением.

3. Расширяемость алгоритма

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

Провайдер криптографических служб (провайдер) обращается к пакету (или ряд пакетов), которые предоставляют конкретную реализацию подмножества аспектов криптографии API Безопасности JDK.

java.security.Provider класс инкапсулирует понятие поставщика систем обеспечения безопасности в платформе Java. Это определяет имя провайдера и перечисляет службы безопасности, которые это реализует. Многократные провайдеры могут быть сконфигурированы одновременно, и перечисляются в порядке предпочтения. Когда службу безопасности требуют, самый высокий приоритетный провайдер, который реализует ту службу, выбирается.

Рисунки 1 и 2 иллюстрируют эти опции для того, чтобы запросить реализацию обзора сообщения MD5. Оба данных показывают трех провайдеров что алгоритмы обзора сообщения реализации. Провайдеры упорядочиваются предпочтением слева направо (1-3). В рисунке 1 приложение запрашивает реализацию алгоритма MD5, не определяя имя провайдера. Провайдеры ищутся в привилегированном порядке и реализации от первого провайдера, предоставляющего, что определенный алгоритм, ProviderB, возвращается. В рисунке 2 приложение запрашивает реализацию алгоритма MD5 от определенного провайдера, ProviderC. На сей раз реализация от того провайдера возвращается, даже при том, что провайдер с более высоким привилегированным порядком, ProviderB, также предоставляет реализацию MD5.

Рисунок 1: рисунок 2 поиска Провайдера: Определенного провайдера требуют

Рисунки 1 и 2 иллюстрируют эти опции для того, чтобы запросить реализацию обзора сообщения MD5. Оба данных показывают трех провайдеров что алгоритмы обзора сообщения реализации. Провайдеры упорядочиваются предпочтением слева направо (1-3). В рисунке 1 приложение запрашивает реализацию алгоритма MD5, не определяя имя провайдера. Провайдеры ищутся в привилегированном порядке и реализации от первого провайдера, предоставляющего, что определенный алгоритм, ProviderB, возвращается. В рисунке 2 приложение запрашивает реализацию алгоритма MD5 от определенного провайдера, ProviderC. На сей раз реализация от того провайдера возвращается, даже при том, что провайдер с более высоким привилегированным порядком, ProviderB, также предоставляет реализацию MD5.

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

Версия Sun среды выполнения Java прибывает стандарт с провайдером по умолчанию, названным "SUN". Другие среды выполнения Java, возможно, не обязательно предоставляют провайдера "SUN".

Кто Должен Считать Этот Документ

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

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

Связанная Документация

Этот документ предполагает, что Вы уже считали Справочник Архитектуры Криптографии Java.

Это документирует пакеты, которые содержат различные классы и интерфейсы в API Безопасности.

• java.security
• java.security.spec
• java.security.interfaces
• javax.crypto
• javax.crypto.spec
• javax.crypto.interfaces

Примечания по Терминологии

• До JDK 1.4, JCE был несвязанным продуктом, и как таковой, JCA и JCE регулярно упоминались как отдельные, отличные компоненты. Поскольку JCE теперь связывается в JDK, различие становится менее очевидным. Так как JCE использует ту же самую архитектуру в качестве JCA, JCE должен более должным образом считаться подмножеством JCA.
• JCA в пределах JDK включает два компонента программного обеспечения:
  • платформа, которая определяет и поддерживает криптографические службы, для который провайдеры предоставляют реализации. Эта платформа включает пакеты такой как java.security, javax.crypto, javax.crypto.spec, и javax.crypto.interfaces.
  • фактические провайдеры, такие как Sun, SunRsaSign, SunJCE, которые содержат фактические криптографические реализации.

Всюду по этому документу срокам JCA отдельно обращается к платформе JCA. Всякий раз, когда этот документ отмечает определенного провайдера JCA, он будет упомянут явно именем провайдера.

Классы механизма и Соответствующие Классы Интерфейса Поставщика услуг

Класс механизма определяет криптографическую службу абстрактным способом (без конкретной реализации).

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

Например, вот четыре класса механизма:

• Signature класс обеспечивает доступ к функциональности алгоритма цифровой подписи.
• DSA KeyFactory класс предоставляет закрытый ключ DSA или открытый ключ (от его кодирования или прозрачной спецификации) в формате, применимом initSign или initVerify методами, соответственно, объекта Подписи DSA.
• Cipher класс обеспечивает доступ к функциональности алгоритма шифрования (такого как DES)
• KeyAgreement класс обеспечивает доступ к функциональности протокола согласования ключей (такого как Diffie-Hellman)

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

• MessageDigest - используемый, чтобы вычислить обзор сообщения (хеш) указанных данных.
• Signature - используемый, чтобы подписать данные и проверить цифровые подписи.
• KeyPairGenerator - используемый, чтобы генерировать пару открытых и закрытых ключей, подходящих для указанного алгоритма.
• KeyFactory - используемый, чтобы преобразовать непрозрачные криптографические ключи типа Key в ключевые спецификации (прозрачные представления базового ключевого материала), и наоборот.
• KeyStore - используемый, чтобы создать и управлять keystore. keystore является базой данных ключей. У закрытых ключей в keystore есть цепочка сертификата, связанная с ними, который аутентифицирует соответствующий открытый ключ. keystore также содержит сертификаты от доверяемых объектов.
• CertificateFactory - используемый, чтобы создать сертификаты с открытым ключом и Списки аннулированных сертификатов (CRL).
• AlgorithmParameters - используемый, чтобы управлять параметрами для определенного алгоритма, включая кодирование параметра и декодирование.
• AlgorithmParameterGenerator - используемый, чтобы генерировать ряд параметров, подходящих для указанного алгоритма.
• SecureRandom - используемый, чтобы генерировать случайные или псевдослучайные числа.
• Cipher: используемый, чтобы зашифровать или дешифровать некоторые указанные данные.
• KeyAgreement: используемый, чтобы выполнить согласование ключей (манипулируют обмен), протокол между 2 или больше сторонами.
• KeyGenerator: используемый, чтобы генерировать секретный (симметричный) ключ, подходящий для указанного алгоритма.
• Mac: используемый, чтобы вычислить код аутентификации сообщений некоторых указанных данных.
• SecretKeyFactory: используемый, чтобы преобразовать непрозрачные криптографические ключи типа SecretKey в ключевые спецификации (прозрачные представления базового ключевого материала), и наоборот.
• ExemptionMechanism: используемый, чтобы обеспечить функциональность механизма освобождения, такого как ключевое восстановление, ключевое ослабление, ключевое условное депонирование, или любой другой (пользовательский) механизм освобождения. Приложениям или апплетам, которые используют механизм освобождения, можно предоставить более сильные возможности шифрования чем те, которые не делают. Однако, пожалуйста, отметьте, что криптографические ограничения больше не требуются для большинства стран, и таким образом механизмы освобождения могут только быть полезными в тех немногих странах, правительства которых передают под мандат ограничения.

Отметьте: генератор создает объекты с совершенно новым содержанием, тогда как фабрика создает объекты из существующего материала (например, кодирование).

Класс механизма обеспечивает интерфейс для функциональности определенного типа криптографической службы (независимый от определенного криптографического алгоритма). Это определяет Прикладной программный интерфейс (API) методы, которые позволяют приложениям получать доступ к определенному типу криптографической службы, которую это обеспечивает. Фактические реализации (от одного или более провайдеров) являются теми для определенных алгоритмов. Например, класс механизма Подписи обеспечивает доступ к функциональности алгоритма цифровой подписи. Фактическая реализация предоставляется в a SignatureSpi подкласс (см. следующий абзац) был бы то, что для определенного вида алгоритма подписи, такого как SHA1 с DSA, SHA1 с RSA, или MD5 с RSA.

Интерфейсы приложения, предоставленные классом механизма, реализуются с точки зрения Интерфейса Поставщика услуг (SPI). Таким образом, для каждого класса механизма есть соответствующий абстрактный класс SPI, который определяет методы Service Provider Interface, которые должны реализовать провайдеры криптографических служб.

Экземпляр класса механизма, "объект API", инкапсулирует (как частное поле) экземпляр соответствующего класса SPI, "объект SPI". Все методы API объекта API объявляются "финалом", и их реализации вызывают соответствующие методы SPI инкапсулировавшего объекта SPI. Экземпляр класса механизма (и его соответствующего класса SPI) создается звонком getInstance метод фабрики класса механизма.

Имя каждого класса SPI является тем же самым как тем из соответствующего класса механизма, сопровождаемого "Spi". Например, класс SPI, соответствующий классу механизма Подписи, является классом SignatureSpi.

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

Другим примером класса механизма является класс MessageDigest, который обеспечивает доступ к алгоритму обзора сообщения. Его реализации, в подклассах MessageDigestSpi, могут быть таковыми из различных алгоритмов обзора сообщения, таких как SHA 1, MD5, или MD2.

Как заключительный пример, класс механизма KeyFactory поддерживает преобразование от непрозрачных ключей до прозрачных ключевых спецификаций, и наоборот. См. Ключевые Интерфейсы Спецификации и Классы, Необходимые Ключевыми Фабриками для деталей. Фактическая реализация, предоставленная в подклассе KeyFactorySpi, состояла бы в том что для определенного типа ключей, например, DSA открытые и закрытые ключи.

Шаги, чтобы Реализовать и Интегрировать Провайдера

Следуйте за шагами ниже, чтобы реализовать провайдера и интегрировать его в платформу JCA:

Шаг 1: Запишите свой Код Реализации Службы

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

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

Для криптографических служб, не определенных в JCA (Например; подписи и обзоры сообщения), пожалуйста, сошлитесь на Справочник Архитектуры Криптографии Java.

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

• SignatureSpi
• MessageDigestSpi
• KeyPairGeneratorSpi
• SecureRandomSpi
• AlgorithmParameterGeneratorSpi
• AlgorithmParametersSpi
• KeyFactorySpi
• CertificateFactorySpi
• KeyStoreSpi
• CipherSpi
• KeyAgreementSpi
• KeyGeneratorSpi
• MacSpi
• SecretKeyFactorySpi
• ExemptionMechanismSpi

(См. Классы Механизма и Соответствующие Классы SPI в этом документе для информации о JCA и другие криптографические классы.)

В Вашем подклассе Вы нуждаетесь к:

1. Реализации предоставления для абстрактных методов, имена которых обычно начинаются engine. См. Дальнейшие Детали Реализации и Требования для дополнительной информации.
2. Гарантируйте, что есть общедоступный конструктор без любых параметров. Вот то, почему: Когда одну из Ваших служб требуют, Безопасность Java ищет подкласс, реализовывая ту службу, как определено свойством в Вашем "мастер классе" (см. Шаг 3). Безопасность Java тогда создает Class объект, связанный с Вашим подклассом, и, создает экземпляр Вашего подкласса, вызывая newInstance метод на этом Class объект. newInstance требует, чтобы у Вашего подкласса был общедоступный конструктор без любых параметров.
3. Конструктор по умолчанию без параметров будет автоматически сгенерирован, если у Вашего подкласса не будет никаких конструкторов. Но если Ваш подкласс определяет каких-либо конструкторов, следует явно определить общедоступного конструктора без параметров.

Шаг 1.1: Дополнительные Требования Провайдера JCA и Рекомендации для Реализаций Шифрования

Инстанцируя реализации провайдера (класс) a Cipher, KeyAgreement, KeyGenerator, MAC или SecretKey фабрика, платформа определит кодовую базу провайдера (файл JAR) и проверит его подпись. Таким образом JCA аутентифицирует провайдера и гарантирует, что только провайдеры, подписанные доверяемым объектом, могут быть включены в JCA. Таким образом одно требование для провайдеров шифрования - то, что они должны быть подписаны, как описано в более поздних шагах.

Кроме того, каждый провайдер должен выполнить проверку самоцелостности, чтобы гарантировать, что файлом JAR, содержащим его код, не управляли в попытке вызвать методы провайдера непосредственно, а не через JCA. Для дополнительной информации см., Как Провайдер Может Сделать Проверку Самоцелостности.

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

• Все классы реализации SPI в пакете провайдера должны быть объявлены final (так, чтобы они не могли быть разделены на подклассы), и их (SPI), методы реализации должны быть объявлены protected.
• У всех crypto-связанных классов помощника в пакете провайдера должен быть частный на пакет контекст, так, чтобы к ним нельзя было получить доступ снаружи пакета провайдера.

Для провайдеров, которые могут быть экспортированы вне США, CipherSpi реализации должны включать реализацию engineGetKeySize метод, который, данный a Key, возвращает размер ключа. Если есть ограничения на доступную криптографическую силу, определенную в файлах политики юрисдикции, каждом Cipher вызовы метода инициализации engineGetKeySize и затем сравнивает результат с максимальным допустимым размером ключа для определенного расположения и обстоятельств апплета или запущенного приложения. Если размер ключа является слишком большим, метод инициализации выдает исключение.

Дополнительные дополнительные функции, которые могут реализовать провайдеры,

• engineWrap и engineUnwrap методы CipherSpi. Обертывание ключа включает безопасной передаче ключа от одного места до другого. Информация об обертывании и разворачивании ключей предоставляется в Обертывании и Разворачивании Ключевого раздела Справочника Архитектуры Криптографии Java.
• один или более механизмов освобождения. Механизм освобождения - что-то, такое как ключевое восстановление, ключевое условное депонирование, или ключевое ослабление, которое, если реализовано и осуществлено, может включить уменьшенным криптографическим ограничениям для приложения (или апплет), который использует это. Для получения информации о требованиях для приложений, которые используют механизмы освобождения, см., Как Подать Заявки, "Освобожденные" от Криптографических Ограничений в Справочнике Архитектуры Криптографии Java.

Шаг 2: Дайте Вашему Провайдеру Имя

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

Шаг 3: Запишите свой Мастер класс, подкласс Провайдера

Третий шаг должен создать подкласс java.security.Provider класс.

Ваш подкласс должен быть a final класс, и его конструктор должны

• вызвать super, определение имени провайдера (см. Шаг 2), номера версии, и строки информации о провайдере и алгоритмах он поддерживает. Например:

      super("CryptoX", 1.0, "CryptoX provider v1.0, implementing " +
          "RSA encryption and key pair generation, and DES encryption.");
  

• установите значения различных свойств, которые требуются для API Безопасности Java искать криптографические службы, реализованные провайдером. Для каждой службы, реализованной провайдером, должно быть свойство, имя которого является типом службы (например; Подпись, MessageDigest, Шифр, KeyAgreement) Подпись, MessageDigest, KeyPairGenerator, SecureRandom, KeyFactory, KeyStore, CertificateFactory, AlgorithmParameterGenerator, AlgorithmParameters, Шифр, KeyAgreement, KeyGenerator, Mac, SecretKeyFactory, или ExemptionMechanism) сопровождаемый периодом и именем алгоритма, к которому применяется служба. Значение свойства должно определить полностью определенное имя класса, реализовывая службу.

• Список ниже показывает различные типы служб JCA, где фактическое имя алгоритма является substitued для algName:

  • Signature.algName
  • MessageDigest.algName
  • KeyPairGenerator.algName
  • SecureRandom.algName
  • AlgorithmParameterGenerator.algName
  • AlgorithmParameters.algName
  • KeyFactory.algName
  • CertificateFactory.algName
  • KeyStore.algName
  • Cipher.algName
  • KeyAgreement.algName
  • KeyGenerator.algName
  • Mac.algName
  • SecretKeyFactory.algName
  • ExemptionMechanism.algName

  Во всех них кроме ExemptionMechanism и Cipher, algName, certType , или storeType "стандартное" имя алгоритма, типа сертификата, или типа keystore. См. Приложение A Справочника Архитектуры Криптографии Java для стандартных имен, которые должны использоваться.)

  В случае ExemptionMechanism, algName обращается к имени механизма освобождения, который может быть одним из следующего: KeyRecovery, KeyEscrow, или KeyWeakening. Случай не имеет значения.

  В случае Cipher, algName может фактически представить преобразование, и может быть составлен из имени алгоритма, определенного режима, и дополнительной схемы. См. Приложение A Справочника Архитектуры Криптографии Java для деталей.

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

  Как пример, провайдер по умолчанию под названием SUN реализует Алгоритм цифровой подписи (чье стандартное имя SHA1withDSA) в названном классе DSA в sun.security.provider пакет. Его подкласс Provider (который является классом Sun в sun.security.provider package) наборы Signature.SHA1withDSA свойство, чтобы иметь значение sun.security.provider.DSA через следующее:

      put("Signature.SHA1withDSA", "sun.security.provider.DSA")
  

  Список ниже показывает больше свойств, которые могут быть определены для различных типов служб, где фактическое имя алгоритма является substitued для algName, типом сертификата для certType, keystore тип для storeType, и название атрибута для attrName:

  • Signature.algName [one or more spaces] attrName
  • MessageDigest.algName [one or more spaces] attrName
  • KeyPairGenerator.algName [one or more spaces] attrName
  • SecureRandom.algName [one or more spaces] attrName
  • KeyFactory.algName [one or more spaces] attrName
  • CertificateFactory.certType [one or more spaces] attrName
  • KeyStore.storeType [one or more spaces] attrName
  • AlgorithmParameterGenerator.algName [one or more spaces] attrName
  • AlgorithmParameters.algName [one or more spaces] attrName
  • Cipher.algName [one or more spaces] attrName
  • KeyAgreement.algName [one or more spaces] attrName
  • KeyGenerator.algName [one or more spaces] attrName
  • Mac.algName [one or more spaces] attrName
  • SecretKeyFactory.algName [one or more spaces] attrName
  • ExemptionMechanism.algName [one or more spaces] attrName

В каждом из них, algName, certType, storeType, или attrName "стандартное" имя алгоритма, типа сертификата, keystore тип, или атрибут. (См. Приложение A Справочника Архитектуры Криптографии Java для стандартных имен, которые должны использоваться.)

Для свойства в вышеупомянутом формате значение свойства должно быть значением для соответствующего атрибута. (См. Приложение A Спецификации API Архитектуры Криптографии Java & Ссылки для определения каждого стандартного атрибута.)

Как пример, провайдер по умолчанию под названием "SUN" реализует SHA1withDSA Digital Алгоритм подписи в программном обеспечении. В мастер классе для провайдера "SUN" это устанавливает Signature.SHA1withDSA ImplementedIn иметь значение Software через следующее:

    put("Signature.SHA1withDSA ImplementedIn", "Software")

Для дальнейших примеров подающего свойства мастер класса см. Приложение A, чтобы просмотреть текущий исходный файл Sun.java или Приложение B, чтобы видеть провайдера SunJCE. Эти файлы показывают как свойства набора провайдеров Sun и SunJCE.

Для каждого сообщения Обзор и алгоритм MAC, укажите, является ли Ваша реализация cloneable. Это не технически необходимо, но это может сэкономить клиентам некоторое время и кодирование, говоря им, передает ли промежуточное звено Обзоры, или MACs может быть возможным посредством клонирования. Клиенты, которые не знают действительно ли a MessageDigest или Mac реализация является cloneable, может узнать, пытаясь клонировать объект и ловя потенциальное исключение, как иллюстрировано следующим примером:

    try {
        // try and clone it
        /* compute the MAC for i1 */
        mac.update(i1);
        byte[] i1Mac = mac.clone().doFinal();

        /* compute the MAC for i1 and i2 */
        mac.update(i2);
        byte[] i12Mac = mac.clone().doFinal();

        /* compute the MAC for i1, i2 and i3 */
        mac.update(i3);
        byte[] i123Mac = mac.doFinal();
    } catch (CloneNotSupportedException cnse) {
        // have to use an approach not involving cloning
    } 

где:

• mac объект MAC, который что они получили, когда они запрашивали один через звонок Mac.getInstance,
• i1, i2 и i3 входные байтовые массивы, и
• они хотят вычислить отдельные хеши для:
  • i1
  • i1 and i2
  • i1, i2, and i3

Генераторы Пары ключей

Для алгоритма генератора пары ключей, в случае, если клиент явно не инициализирует генератор пары ключей (через звонок initialize метод), каждый провайдер должен предоставить и задокументировать инициализацию по умолчанию. Например, генератор пары ключей Diffie-Hellman, предоставленный провайдером SunJCE, использует главный размер модуля по умолчанию (keysize) из 1024 битов.

Ключевые Фабрики

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

Генераторы Параметра алгоритма

В случае, если клиент явно не инициализирует генератор параметра алгоритма (через звонок init метод в AlgorithmParameterGenerator класс механизма), каждый провайдер должен предоставить и задокументировать инициализацию по умолчанию. Например, провайдер SunJCE использует главный размер модуля по умолчанию (keysize) из 1024 битов для генерации параметров Diffie-Hellman, провайдер Sun модуль по умолчанию главный размер 1024 битов для генерации параметров DSA.

Алгоритмы подписи

Если Вы реализуете алгоритм подписи, следует задокументировать формат в который подпись (сгенерированный одним из sign методы), кодируется. Например, алгоритм подписи SHA1withDSA, предоставленный провайдером "SUN", кодирует подпись стандартом ASN.1 SEQUENCE из двух целых чисел, r и s.

Генерация случайных чисел (SecureRandom) Алгоритмы

Для алгоритма генерации случайных чисел предоставьте информацию относительно того, насколько "случайный" сгенерированные числа, и качество семени, когда генератор случайных чисел является самоотбором. Также отметьте то, что происходит, когда объект SecureRandom (и его инкапсулировавший объект реализации SecureRandomSpi) десериализовываются: Если последующие звонки nextBytes метод (который вызывает engineNextBytes метод инкапсулировавшего объекта SecureRandomSpi) восстановленного объектного урожая, те же самые (случайные) байты как исходный объект были бы, затем позвольте пользователям знать, что, если это поведение является нежелательным, они должны отобрать восстановленный случайный объект, вызывая setSeed метод.

Фабрики сертификата

Провайдер должен задокументировать, какие типы сертификатов (и их номера версий, если релевантный), может быть создан фабрикой.

Keystores

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

Шаг 12: Сделайте свои Файлы Класса и Документацию Доступными для Клиентов

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

Имена псевдонима

Для многих криптографических алгоритмов и типов, есть единственное официальное "стандартное имя", определенное в Приложении A Справочника Архитектуры Криптографии Java.

Например, "MD5" является стандартным именем для сообщения RSA-MD5 алгоритм Обзора, определенный RSA DSI в RFC 1321. DiffieHellman стандарт для алгоритма согласования ключей Diffie-Hellman, определенного в PKCS3.

В JDK есть схема искажения, которая позволяет клиентам использовать псевдонимы, относясь к алгоритмам или типам, а не их стандартным именам. Например, мастер класс провайдера "SUN" (Sun.java) определяет псевдоним "SHA1/DSA" для алгоритма, стандартное имя которого является "SHA1withDSA". Таким образом следующие операторы эквивалентны:

    Signature sig = Signature.getInstance("SHA1withDSA", "SUN");

    Signature sig = Signature.getInstance("SHA1/DSA", "SUN");

Псевдонимы могут быть определены в Вашем "мастер классе" (см. Шаг 3). Чтобы определить псевдоним, создайте названное свойство

    Alg.Alias.engineClassName.aliasName

где engineClassName является именем класса механизма (например, Signature), и aliasName является Вашим именем псевдонима. Значение свойства должно быть стандартным алгоритмом (или тип) имя для алгоритма (или тип) быть искаженным.

Как пример, провайдер "SUN" определяет псевдоним "SHA1/DSA" для алгоритма подписи, стандартное имя которого является "SHA1withDSA", устанавливая названное свойство Alg.Alias.Signature.SHA1/DSA иметь значение SHA1withDSA через следующее:

    put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA");

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

Взаимозависимости службы

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

Если Вы реализуете один тип алгоритма, который требует другого, можно сделать одно из следующего:

1. Предоставьте свои собственные реализации обоим.
2. Позвольте своей реализации одного алгоритма использовать экземпляр другого типа алгоритма, как предоставлено провайдером Sun по умолчанию, который включается с каждым Java установка Платформы SE. Например, если Вы реализуете алгоритм PBE, который требует алгоритма обзора сообщения, можно получить экземпляр класса, реализовывая алгоритм обзора сообщения MD5, вызывая

       MessageDigest.getInstance("MD5", "SUN")
   
   

3. Позвольте своей реализации одного алгоритма использовать экземпляр другого типа алгоритма, как предоставлено другим определенным провайдером. Это является только соответствующим, если Вы уверены, что всем клиентам, которые будут использовать Вашего провайдера, также установят другого провайдера.
4. Позвольте своей реализации одного алгоритма использовать экземпляр другого типа алгоритма, как предоставлено другим (неуказанным) провайдером. Таким образом, можно запросить алгоритм по имени, но не определяя определенного провайдера, как в

       MessageDigest.getInstance("MD5")
   
   

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

Вот некоторые общие типы взаимозависимостей алгоритма:

Подпись и Алгоритмы Обзора сообщения

Алгоритм подписи часто требует использования алгоритма обзора сообщения. Например, алгоритм подписи SHA1withDSA требует SHA 1 алгоритм обзора сообщения.

Подпись и (псевдо-) Алгоритмы Генерации случайных чисел

Алгоритм подписи часто требует использования (псевдо-) алгоритм генерации случайных чисел. Например, такой алгоритм требуется, чтобы генерировать подпись DSA.

Генерация Пары ключей и Алгоритмы Обзора сообщения

Алгоритм генерации пары ключей часто требует использования алгоритма обзора сообщения. Например, ключи DSA сгенерированы, используя SHA 1 алгоритм обзора сообщения.

Генерация Параметра алгоритма и Алгоритмы Обзора сообщения

Генератор параметра алгоритма часто требует использования алгоритма обзора сообщения. Например, параметры DSA сгенерированы, используя SHA 1 алгоритм обзора сообщения.

KeyStores и Алгоритмы Обзора сообщения

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

Алгоритмы Генерации Пары ключей и Генераторы Параметра Алгоритма

Алгоритм генерации пары ключей иногда должен генерировать новый набор параметров алгоритма. Это может или генерировать параметры непосредственно, или использовать генератор параметра алгоритма.

Генерация Пары ключей, Генерация Параметра Алгоритма, и (псевдо-) Алгоритмы Генерации случайных чисел

Алгоритм генерации пары ключей может потребовать источника случайности, чтобы генерировать новую пару ключей и возможно новый набор параметров, связанных с ключами. Тот источник случайности представляется a SecureRandom объект. Реализация алгоритма генерации пары ключей может генерировать основные параметры самостоятельно, или может использовать генератор параметра алгоритма, чтобы генерировать их, когда это может или, возможно, не инициализирует генератор параметра алгоритма с источником случайности.

Генераторы Параметра алгоритма и Параметры Алгоритма

Генератор параметра алгоритма engineGenerateParameters метод должен возвратиться AlgorithmParameters экземпляр.

Подпись и Алгоритмы Генерации Пары ключей или Ключевые Фабрики

Если Вы реализуете алгоритм подписи, Ваша реализация engineInitSign и engineInitVerify методы потребуют, передал - в ключах, которые допустимы для базового алгоритма (например, ключи DSA для алгоритма DSS). Можно сделать одно из следующего:

1. Также создайте свои собственные классы, реализовывая соответствующие интерфейсы (например, классы, реализовывая DSAPrivateKey и DSAPublicKey интерфейсы от пакета java.security.interfaces), и создайте свой собственный генератор пары ключей и/или манипулируйте ключи возврата фабрики тех типов. Потребуйте ключей, к которым передают engineInitSign и engineInitVerify чтобы быть типами ключей, Вы реализовали, то есть, ключи, сгенерированные от Вашего генератора пары ключей, или манипулируете фабрику. Или Вы можете,
2. Примите ключи от других генераторов пары ключей или других ключевых фабрик, пока они - экземпляры соответствующих интерфейсов, которые позволяют Вашей реализации подписи получить информацию, в которой она нуждается (такие как закрытые и открытые ключи и основные параметры). Например, engineInitSign метод для класса Подписи DSS мог принять любые закрытые ключи, которые являются экземплярами java.security.interfaces.DSAPrivateKey.

KeyStores и Фабрики Ключа и Сертификата

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

Инициализации по умолчанию

В случае, если клиент явно не инициализирует генератор пары ключей или генератор параметра алгоритма, каждый провайдер такой службы должен предоставить (и документ) инициализацию по умолчанию. Например, провайдер Sun использует размер модуля по умолчанию (сила) 1024 битов для генерации параметров DSA, и провайдер "SunJCE" использует размер модуля по умолчанию (размер ключа) 1024 битов для генерации параметров Diffie-Hellman.

Требования Параметра Генератора Пары ключей по умолчанию

Если Вы реализуете генератор пары ключей, Ваша реализация должна предоставить параметры по умолчанию, которые используются, когда клиенты не определяют параметры. Документация, которую Вы предоставляете (Шаг 11), должна утвердить, каковы параметры по умолчанию.

Например, генератор пары ключей DSA в провайдере солнца предоставляет ряд предварительно вычисленного p, q, и g значения по умолчанию для генерации 512, 768, и 1024-разрядные пары ключей. Следующий p, q, и g значения используются в качестве значений по умолчанию для генерации 1024-разрядных пар ключей DSA:

p = fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80
    b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b
    801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6
    1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675
    f3ae2b61 d72aeff2 2203199d d14801c7

q = 9760508f 15230bcc b292b982 a2eb840b f0581cf5

g = f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b
    3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613
    b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f
    0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06
    928b665e 807b5525 64014c3b fecf492a

( p и q значения, данные здесь, были сгенерированы главным стандартом генерации, используя 160-разрядное

SEED:  8d515589 4229d5e6 89ee01e6 018a237e 2cae64cd

С этим семенем находится алгоритм p и q когда счетчик был в 92.)

Provider.Service Класс

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

A Provider.Service объект инкапсулирует всю информацию о службе. Это - провайдер, который предлагает услугу, ее тип (например. MessageDigest или Signature), имя алгоритма, и имя класса, который реализует службу. Дополнительно, это также включает список альтернативных имен алгоритма для этой службы (псевдонимы) и атрибуты, которые являются картой (имя, значение) Строковые пары. Кроме того, это определяет методы newInstance() и supportsParameter(). Они имеют реализации по умолчанию, но могут быть переопределены провайдерами если нужно, как может иметь место с провайдерами, которые взаимодействуют через интерфейс с маркерами аппаратного модуля безопасности.

newInstance() метод используется платформой безопасности, когда это должно создать новые экземпляры реализации. Реализация по умолчанию использует отражение, чтобы вызвать стандартного конструктора для соответствующего типа службы. Для всех стандартных служб кроме CertStore, это не-args конструктор. constructorParameter к newInstance() должен быть нуль в случаях тезисов. Для служб типа CertStore, конструктор, который берет a CertStoreParameters объект вызывается, и constructorParameter должен быть ненулевым экземпляром CertStoreParameters. Поставщик систем обеспечения безопасности может переопределить newInstance() метод, чтобы реализовать инстанцирование как соответствующий для той реализации. Это могло использовать прямой вызов или вызвать конструктора, который передает дополнительную информацию, определенную для экземпляра Провайдера или маркера. Например, если многократные читатели Smartcard присутствуют на системе, она могла бы передать информацию, о котором читателе недавно создаваемая служба должна быть связана с. Однако, несмотря на настройку все реализации должны следовать за соглашениями о constructorParameter, описанном выше.

supportsParameter() тесты, может ли Служба использовать указанный параметр. Это возвращает false, если эта служба не может использовать параметр. Это возвращает true, если эта служба может использовать параметр, если быстрый тест неосуществим, или если состояние неизвестно. Это используется платформой безопасности с некоторыми типами служб, чтобы быстро исключить несоответствие реализаций из рассмотрения. Это в настоящий момент только определяется для следующих стандартных служб: Signature, Cipher, Mac, и KeyAgreement. parameter должен быть экземпляром Key в этих случаях. Например, для Signature службы, платформа тестирует, может ли служба использовать предоставленный Ключ прежде, чем инстанцировать службы. Реализация по умолчанию исследует атрибуты SupportedKeyFormats и SupportedKeyClasses как описано ниже. Снова, провайдер может переопределить это методы, чтобы реализовать дополнительные тесты.

SupportedKeyFormats атрибут является списком поддерживаемых форматов для закодированных ключей (как возвращено key.getFormat()) разделенный "|" (канал) символ. Например, X.509|PKCS#8. SupportedKeyClasses атрибут является списком имен классов интерфейсов, разделенных "|" символ. Ключевой объект, как полагают, является приемлемым, если это присваиваемо по крайней мере одному из тех классов или названных интерфейсов. Другими словами, если класс ключевого объекта является подклассом одного из перечисленных классов (или класса непосредственно) или если это реализует перечисленный интерфейс. Значение в качестве примера "java.security.interfaces.RSAPrivateKey|java.security.interfaces.RSAPublicKey" .

Четыре метода были добавлены к классу Провайдера для добавления и поиска Служб. Как отмечалось ранее реализация тех методов и также существующих методов Properties была специально предназначена, чтобы гарантировать совместимость существующими подклассами Провайдера. Это достигается следующим образом:

Если методы Properties наследства используются, чтобы добавить записи, класс Провайдера удостоверяется, что строки свойства анализируются в эквивалентные объекты Службы до поиска через getService(). Точно так же, если метод putService() используется, эквивалентные строки свойства помещаются в хеш-таблицу провайдера одновременно. Если реализация провайдера переопределяет какой-либо из методов в классе Провайдера, она должна гарантировать, что его реализация не вмешивается в это преобразование. Чтобы избежать проблем, мы рекомендуем, чтобы реализации не переопределили ни одного из методов в Provider класс.

Форматы подписи

Если Вы реализуете алгоритм подписи, документация, которую Вы предоставляете (Шаг 11), должна определить формат в который подпись (сгенерированный одним из sign методы), кодируется.

Например, алгоритм подписи SHA1withDSA, предоставленный провайдером Sun, кодирует подпись стандартной последовательностью ASN.1 два ASN.1 INTEGER значения: r и s, в том порядке:

SEQUENCE ::= {
        r INTEGER,
        s INTEGER }

Интерфейсы DSA и их Необходимые Реализации

API Безопасности Java содержит следующие интерфейсы (в java.security.interfaces пакет) для удобства программистов, реализующих службы DSA:

• DSAKey
• DSAKeyPairGenerator
• DSAParams
• DSAPrivateKey
• DSAPublicKey

Следующие разделы обсуждают требования для реализаций этих интерфейсов.

DSAKeyPairGenerator Реализация

Этот интерфейс является устаревшим. Это имело обыкновение быть необходимым, чтобы позволить клиентам обеспечить специфичные для DSA параметры, которые будут использоваться, а не параметры по умолчанию Ваши предоставления реализации. Однако, в Java это больше не необходимо; новое KeyPairGenerator initialize метод, который берет AlgorithmParameterSpec параметр позволяет клиентам указать на специфичные для алгоритма параметры.

DSAParams Реализация

Если Вы реализуете генератор пары ключей DSA, Вы нуждаетесь в реализации класса DSAParams для содержания и возврата p, q, и g параметры.

A DSAParams реализация также требуется, если Вы реализуете DSAPrivateKey и DSAPublicKey интерфейсы. DSAPublicKey и DSAPrivateKey оба расширяют интерфейс DSAKey, который содержит a getParams метод, который должен возвратить a DSAParams объект. См. Реализации DSAPrivateKey и DSAPublicKey для получения дополнительной информации.

Отметьте: есть a DSAParams реализация встраивала в JDK: java.security.spec.DSAParameterSpec класс.

DSAPrivateKey и DSAPublicKey Реализации

Если Вы реализуете генератор пары ключей DSA или манипулируете фабрику, Вы должны создать классы, реализовывая DSAPrivateKey и DSAPublicKey интерфейсы.

Если Вы реализуете генератор пары ключей DSA, Ваш generateKeyPair метод (в Вашем KeyPairGeneratorSpi подкласс), возвратит экземпляры Ваших реализаций тех интерфейсов.

Если Вы реализуете ключевую фабрику DSA, Ваш engineGeneratePrivate метод (в Вашем KeyFactorySpi подкласс), возвратит экземпляр Вашего DSAPrivateKey реализация, и Ваш engineGeneratePublic метод возвратит экземпляр Вашего DSAPublicKey реализация.

Кроме того, Ваш engineGetKeySpec и engineTranslateKey методы будут ожидать, что переданным - в ключе будет экземпляр a DSAPrivateKey или DSAPublicKey реализация. getParams метод, обеспеченный интерфейсными реализациями, полезен для получения и извлечения параметров от ключей и затем использования параметров, например как параметры к DSAParameterSpec конструктор вызывал, чтобы создать спецификацию параметра из значений параметра, которые могли использоваться, чтобы инициализировать a KeyPairGenerator объект для DSA.

Если Вы реализуете алгоритм подписи DSA, Ваш engineInitSign метод (в Вашем SignatureSpi подкласс), будет ожидать быть переданным a DSAPrivateKey и Ваш engineInitVerify метод будет ожидать быть переданным a DSAPublicKey.

Пожалуйста, отметьте: DSAPublicKey и DSAPrivateKey интерфейсы определяют очень универсальный, независимый от провайдера интерфейс к DSA открытые и закрытые ключи, соответственно. engineGetKeySpec и engineTranslateKey методы (в Вашем KeyFactorySpi подкласс), мог дополнительно проверить, является ли переданным - в ключе фактически экземпляр собственной реализации их провайдера DSAPrivateKey или DSAPublicKey, например, чтобы использовать в своих интересах специфичные для провайдера детали реализации. То же самое является истиной для алгоритма подписи DSA engineInitSign и engineInitVerify методы (в Вашем SignatureSpi подкласс).

Видеть, какие методы должны быть реализованы классами, которые реализуют DSAPublicKey и DSAPrivateKey интерфейсы, сначала отметьте следующие интерфейсные подписи:

В java.security.interfaces пакет:

   public interface DSAPrivateKey extends DSAKey,
                java.security.PrivateKey

   public interface DSAPublicKey extends DSAKey,
                java.security.PublicKey

   public interface DSAKey 

В java.security пакет:

   public interface PrivateKey extends Key

   public interface PublicKey extends Key

   public interface Key extends java.io.Serializable 

Чтобы реализовать DSAPrivateKey и DSAPublicKey интерфейсы, следует реализовать методы, которые они определяют так же как определенные интерфейсами, которые они расширяют, прямо или косвенно.

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

• getX метод от DSAPrivateKey интерфейс.
• getParams метод от java.security.interfaces.DSAKey интерфейс, с тех пор DSAPrivateKey расширяется DSAKey. Отметьте: getParams метод возвращает a DSAParams объект, таким образом, у Вас должен также быть a DSAParams реализация.
• getAlgorithm, getEncoded, и getFormat методы от java.security.Key интерфейс, с тех пор DSAPrivateKey расширяется java.security.PrivateKey, и PrivateKey расширяется Key.

  Точно так же для общедоступных ключей DSA, Вы должны предоставить класс, который реализует:

  • getY метод от интерфейса DSAPublicKey.
  • getParams метод от java.security.interfaces.DSAKey интерфейс, с тех пор DSAPublicKey расширяет DSAKey. Отметьте: getParams метод возвращает a DSAParams объект, таким образом, у Вас должен также быть a DSAParams реализация.
  • getAlgorithm, getEncoded, и getFormat методы от java.security.Key интерфейс, с тех пор DSAPublicKey расширяется java.security.PublicKey, и PublicKey расширяется Key.

Интерфейсы RSA и их Необходимые Реализации

    public interface RSAPrivateKey extends java.security.PrivateKey

    public interface RSAPrivateCrtKey extends RSAPrivateKey

    public interface RSAPublicKey extends java.security.PublicKey

    public interface PrivateKey extends Key

    public interface PublicKey extends Key

    public interface Key extends java.io.Serializable

    public interface DHPrivateKey extends DHKey, java.security.PrivateKey

    public interface DHPublicKey extends DHKey, java.security.PublicKey

    public interface DHKey 

    public interface PrivateKey extends Key

    public interface PublicKey extends Key

    public interface Key extends java.io.Serializable 

    public BigInteger getP()

    public BigInteger getQ()

    public BigInteger getG()

    put("Alg.Alias.<engine_type>.1.2.3.4.5.6.7.8",
        "<algorithm_alias_name>");

    % keytool -genkeypair -sigalg 1.2.3.4.5.6.7.8

    put("Signature.Foo", "com.xyz.MyFooSignatureImpl");
    put("Alg.Alias.Signature.1.2.3.4.5.6.7.8", "Foo");

    put("KeyFactory.Foo", "com.xyz.MyFooKeyFactoryImpl");
    put("Alg.Alias.KeyFactory.1.2.3.4.5.6.7.8", "Foo");

    put("Alg.Alias.Signature.OID.1.2.3.4.5.6.7.8", "MySigAlg");

/*
 * @(#)Sun.java 1.28 99/05/27
 *
 * Copyright (c) 1996, 1998, Oracle and/or its affiliates. All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   - Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *
 *   - Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in the
 *     documentation and/or other materials provided with the distribution.
 *
 *   - Neither the name of Oracle nor the names of its
 *     contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
 * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

package sun.security.provider;

import java.io.*;
import java.util.*;
import java.security.*;

/**
 * The SUN Security Provider.
 *
 * @author Benjamin Renaud
 *
 * @version 1.28, 05/27/99
 */

/**
 * Defines the SUN provider.
 *
 * Algorithms supported, and their names:
 *
 * - SHA is the message digest scheme described in FIPS 180-1.
 *   Aliases for SHA are SHA-1 and SHA1.
 *
 * - SHA1withDSA is the signature scheme described in FIPS 186.
 *   (SHA used in DSA is SHA-1: FIPS 186 with Change No 1.)
 *   Aliases for SHA1withDSA are DSA, DSS, SHA/DSA, SHA-1/DSA, SHA1/DSA,
 *   SHAwithDSA, DSAWithSHA1, and the object
 *   identifier strings "OID.1.3.14.3.2.13", "OID.1.3.14.3.2.27" and
 *   "OID.1.2.840.10040.4.3".
 *
 * - DSA is the key generation scheme as described in FIPS 186.
 *   Aliases for DSA include the OID strings "OID.1.3.14.3.2.12"
 *   and "OID.1.2.840.10040.4.1".
 *
 * - MD5 is the message digest scheme described in RFC 1321.
 *   There are no aliases for MD5.
 */

public final class Sun extends Provider {

    private static final String INFO = "SUN " +
    "(DSA key/parameter generation; DSA signing; " +
    "SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore)";

    public Sun() {
        /* We are the SUN provider */
        super("SUN", 1.2, INFO);

        AccessController.doPrivileged(new java.security.PrivilegedAction() {
            public Object run() {

                /*
                 * Signature engines
                 */
                put("Signature.SHA1withDSA", "sun.security.provider.DSA");

                put("Alg.Alias.Signature.DSA", "SHA1withDSA");
                put("Alg.Alias.Signature.DSS", "SHA1withDSA");
                put("Alg.Alias.Signature.SHA/DSA", "SHA1withDSA");
                put("Alg.Alias.Signature.SHA-1/DSA", "SHA1withDSA");
                put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA");
                put("Alg.Alias.Signature.SHAwithDSA", "SHA1withDSA");
                put("Alg.Alias.Signature.DSAWithSHA1", "SHA1withDSA");
                put("Alg.Alias.Signature.OID.1.2.840.10040.4.3",
                    "SHA1withDSA");
                put("Alg.Alias.Signature.1.2.840.10040.4.3", "SHA1withDSA");
                put("Alg.Alias.Signature.1.3.14.3.2.13", "SHA1withDSA");
                put("Alg.Alias.Signature.1.3.14.3.2.27", "SHA1withDSA");

                /*
                 *  Key Pair Generator engines
                 */
                put("KeyPairGenerator.DSA",
                    "sun.security.provider.DSAKeyPairGenerator");
                put("Alg.Alias.KeyPairGenerator.OID.1.2.840.10040.4.1", "DSA");
                put("Alg.Alias.KeyPairGenerator.1.2.840.10040.4.1", "DSA");
                put("Alg.Alias.KeyPairGenerator.1.3.14.3.2.12", "DSA");

                /*
                 * Digest engines
                 */
                put("MessageDigest.MD5", "sun.security.provider.MD5");
                put("MessageDigest.SHA", "sun.security.provider.SHA");

                put("Alg.Alias.MessageDigest.SHA-1", "SHA");
                put("Alg.Alias.MessageDigest.SHA1", "SHA");

                /*
                 * Algorithm Parameter Generator engines
                 */
                put("AlgorithmParameterGenerator.DSA",
                    "sun.security.provider.DSAParameterGenerator");

                /*
                 * Algorithm Parameter engines
                 */
                put("AlgorithmParameters.DSA",
                    "sun.security.provider.DSAParameters");
                put("Alg.Alias.AlgorithmParameters.1.3.14.3.2.12", "DSA");
                put("Alg.Alias.AlgorithmParameters.1.2.840.10040.4.1", "DSA");

                /*
                 * Key factories
                 */
                put("KeyFactory.DSA", "sun.security.provider.DSAKeyFactory");
                put("Alg.Alias.KeyFactory.1.3.14.3.2.12", "DSA");
                put("Alg.Alias.KeyFactory.1.2.840.10040.4.1", "DSA");

                /*
                 * SecureRandom
                 */
                 put("SecureRandom.SHA1PRNG",
                     "sun.security.provider.SecureRandom");

                /*
                 * Certificates
                 */
                put("CertificateFactory.X509",
                    "sun.security.provider.X509Factory");
                put("Alg.Alias.CertificateFactory.X.509", "X509");

                /*
                 * KeyStore
                 */
                put("KeyStore.JKS", "sun.security.provider.JavaKeyStore");

                /*
                 * KeySize
                 */
                put("Signature.SHA1withDSA KeySize", "1024");
                put("KeyPairGenerator.DSA KeySize", "1024");
                put("AlgorithmParameterGenerator.DSA KeySize", "1024");

                /*
                 * Implementation type: software or hardware
                 */
                put("Signature.SHA1withDSA ImplementedIn", "Software");
                put("KeyPairGenerator.DSA ImplementedIn", "Software");
                put("MessageDigest.MD5 ImplementedIn", "Software");
                put("MessageDigest.SHA ImplementedIn", "Software");
                put("AlgorithmParameterGenerator.DSA ImplementedIn",
                    "Software");
                put("AlgorithmParameters.DSA ImplementedIn", "Software");
                put("KeyFactory.DSA ImplementedIn", "Software");
                put("SecureRandom.SHA1PRNG ImplementedIn", "Software");
                put("CertificateFactory.X509 ImplementedIn", "Software");
                put("KeyStore.JKS ImplementedIn", "Software");

                return null;
            }
        });
    }
}

/*
 * @(#)SunJCE.java      1.73 05/12/13
 *
 * Copyright (c) 2006, Oracle and/or its affiliates. All rights reserved.
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */

package com.sun.crypto.provider;

import java.security.*;
import java.security.cert.*;
import java.net.URL;
import java.io.ByteArrayInputStream;

/**
 * The "SunJCE" Cryptographic Service Provider.
 *
 * @author Jan Luehe
 * @author Sharon Liu
 *
 * @version 1.73, 12/13/05
 */

/**
 * Defines the "SunJCE" provider.
 *
 * Supported algorithms and their names:
 *
 * ...edited for space...
 *
 */

public final class SunJCE extends Provider {

    private static final String info = "SunJCE Provider " +
    "(implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, "
    + "Diffie-Hellman, HMAC)";

    private static final String OID_PKCS5_MD5_DES = "1.2.840.113549.1.5.3";
    private static final String OID_PKCS3 = "1.2.840.113549.1.3.1";

    public SunJCE() {
        /* We are the "SunJCE" provider */
        super("SunJCE", 1.6d, info);

        final String BLOCK_MODES = "ECB|CBC|PCBC|CTR|CTS|CFB|OFB" +
            "|CFB8|CFB16|CFB24|CFB32|CFB40|CFB48|CFB56|CFB64" +
            "|OFB8|OFB16|OFB24|OFB32|OFB40|OFB48|OFB56|OFB64";
        final String BLOCK_MODES128 = BLOCK_MODES +
            "|CFB72|CFB80|CFB88|CFB96|CFB104|CFB112|CFB120|CFB128" +
            "|OFB72|OFB80|OFB88|OFB96|OFB104|OFB112|OFB120|OFB128";
        final String BLOCK_PADS = "NOPADDING|PKCS5PADDING|ISO10126PADDING";

        AccessController.doPrivileged(new java.security.PrivilegedAction() {
                public Object run() {

                /*
                 * Cipher engines
                 */
                put("Cipher.RSA", "com.sun.crypto.provider.RSACipher");
                put("Cipher.RSA SupportedModes", "ECB");
                put("Cipher.RSA SupportedPaddings",
                        "NOPADDING|PKCS1PADDING|OAEPWITHMD5ANDMGF1PADDING"
                        + "|OAEPWITHSHA1ANDMGF1PADDING"
                        + "|OAEPWITHSHA-1ANDMGF1PADDING"
                        + "|OAEPWITHSHA-256ANDMGF1PADDING"
                        + "|OAEPWITHSHA-384ANDMGF1PADDING"
                        + "|OAEPWITHSHA-512ANDMGF1PADDING");
                put("Cipher.RSA SupportedKeyClasses",
                        "java.security.interfaces.RSAPublicKey" +
                        "|java.security.interfaces.RSAPrivateKey");

                put("Cipher.PBEWithMD5AndDES",
                    "com.sun.crypto.provider.PBEWithMD5AndDESCipher");
                put("Alg.Alias.Cipher.OID."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");
                put("Alg.Alias.Cipher."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");

                put("Cipher.AES", "com.sun.crypto.provider.AESCipher");
                put("Alg.Alias.Cipher.Rijndael", "AES");
                put("Cipher.AES SupportedModes", BLOCK_MODES128);
                put("Cipher.AES SupportedPaddings", BLOCK_PADS);
                put("Cipher.AES SupportedKeyFormats", "RAW");

                put("Cipher.AESWrap", "com.sun.crypto.provider.AESWrapCipher");
                put("Cipher.AESWrap SupportedModes", "ECB");
                put("Cipher.AESWrap SupportedPaddings", "NOPADDING");
                put("Cipher.AESWrap SupportedKeyFormats", "RAW");

                put("Cipher.ARCFOUR",
                    "com.sun.crypto.provider.ARCFOURCipher");
                put("Alg.Alias.Cipher.RC4", "ARCFOUR");
                put("Cipher.ARCFOUR SupportedModes", "ECB");
                put("Cipher.ARCFOUR SupportedPaddings", "NOPADDING");
                put("Cipher.ARCFOUR SupportedKeyFormats", "RAW");

                /*
                 *  Key(pair) Generator engines
                 */
                put("KeyGenerator.AES",
                    "com.sun.crypto.provider.AESKeyGenerator");
                put("Alg.Alias.KeyGenerator.Rijndael", "AES");

                put("KeyGenerator.ARCFOUR",
                    "com.sun.crypto.provider.KeyGeneratorCore$" +
                    "ARCFOURKeyGenerator");
                put("Alg.Alias.KeyGenerator.RC4", "ARCFOUR");

                put("KeyGenerator.HmacMD5",
                    "com.sun.crypto.provider.HmacMD5KeyGenerator");

                put("KeyGenerator.HmacSHA256",
                    "com.sun.crypto.provider.KeyGeneratorCore$HmacSHA256KG");

                put("KeyPairGenerator.DiffieHellman",
                    "com.sun.crypto.provider.DHKeyPairGenerator");
                put("Alg.Alias.KeyPairGenerator.DH", "DiffieHellman");
                put("Alg.Alias.KeyPairGenerator.OID."+OID_PKCS3,
                    "DiffieHellman");
                put("Alg.Alias.KeyPairGenerator."+OID_PKCS3,
                    "DiffieHellman");

                /*
                 * Algorithm parameter generation engines
                 */
                put("AlgorithmParameterGenerator.DiffieHellman",
                    "com.sun.crypto.provider.DHParameterGenerator");
                put("Alg.Alias.AlgorithmParameterGenerator.DH",
                    "DiffieHellman");
                put("Alg.Alias.AlgorithmParameterGenerator.OID."+OID_PKCS3,
                    "DiffieHellman");
                put("Alg.Alias.AlgorithmParameterGenerator."+OID_PKCS3,
                    "DiffieHellman");

                /*
                 * Key Agreement engines
                 */
                put("KeyAgreement.DiffieHellman",
                    "com.sun.crypto.provider.DHKeyAgreement");
                put("Alg.Alias.KeyAgreement.DH", "DiffieHellman");
                put("Alg.Alias.KeyAgreement.OID."+OID_PKCS3, "DiffieHellman");
                put("Alg.Alias.KeyAgreement."+OID_PKCS3, "DiffieHellman");

                put("KeyAgreement.DiffieHellman SupportedKeyClasses",
                    "javax.crypto.interfaces.DHPublicKey" +
                    "|javax.crypto.interfaces.DHPrivateKey");

                /*
                 * Algorithm Parameter engines
                 */
                put("AlgorithmParameters.DiffieHellman",
                    "com.sun.crypto.provider.DHParameters");
                put("Alg.Alias.AlgorithmParameters.DH", "DiffieHellman");
                put("Alg.Alias.AlgorithmParameters.OID."+OID_PKCS3,
                    "DiffieHellman");
                put("Alg.Alias.AlgorithmParameters."+OID_PKCS3,
                    "DiffieHellman");

                put("AlgorithmParameters.PBEWithMD5AndDES",
                    "com.sun.crypto.provider.PBEParameters");
                put("Alg.Alias.AlgorithmParameters.OID."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");
                put("Alg.Alias.AlgorithmParameters."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");

                put("AlgorithmParameters.OAEP",
                    "com.sun.crypto.provider.OAEPParameters");

                /*
                 * Key factories
                 */
                put("KeyFactory.DiffieHellman",
                    "com.sun.crypto.provider.DHKeyFactory");
                put("Alg.Alias.KeyFactory.DH", "DiffieHellman");
                put("Alg.Alias.KeyFactory.OID."+OID_PKCS3,
                    "DiffieHellman");
                put("Alg.Alias.KeyFactory."+OID_PKCS3, "DiffieHellman");

                /*
                 * Secret-key factories
                 */
                put("SecretKeyFactory.PBEWithMD5AndDES",
                    "com.sun.crypto.provider.PBEKeyFactory$PBEWithMD5AndDES"
                    );
                put("Alg.Alias.SecretKeyFactory.OID."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");
                put("Alg.Alias.SecretKeyFactory."+OID_PKCS5_MD5_DES,
                    "PBEWithMD5AndDES");

                /*
                 * MAC
                 */
                put("Mac.HmacMD5", "com.sun.crypto.provider.HmacMD5");
                put("Mac.HmacSHA256",
                    "com.sun.crypto.provider.HmacCore$HmacSHA256");

                put("Mac.HmacMD5 SupportedKeyFormats", "RAW");
                put("Mac.HmacSHA256 SupportedKeyFormats", "RAW");

                /*
                 * KeyStore
                 */
                put("KeyStore.JCEKS", "com.sun.crypto.provider.JceKeyStore");

                return null;
            }
        });
    }
}
 

<java-home>/lib/security/java.security     [Solaris]
<java-home>\lib\security\java.security     [Win32]

#
# This is the "master security properties file".
#
# In this file, various security properties are set for use by
# java.security classes. This is where users can statically register
# Cryptography Package Providers ("providers" for short). The term
# "provider" refers to a package or set of packages that supply a
# concrete implementation of a subset of the cryptography aspects of
# the Java Security API. A provider may, for example, implement one or
# more digital signature algorithms or message digest algorithms.
#
# Each provider must implement a subclass of the Provider class.
# To register a provider in this master security properties file,
# specify the Provider subclass name and priority in the format
#
#    security.provider.<n>=<className>
#
# This declares a provider, and specifies its preference
# order n. The preference order is the order in which providers are
# searched for requested algorithms (when no specific provider is
# requested). The order is 1-based; 1 is the most preferred, followed
# by 2, and so on.
#
# <className> must specify the subclass of the Provider class whose
# constructor sets the values of various properties that are required
# for the Java Security API to look up the algorithms or other
# facilities implemented by the provider.
#
# There must be at least one provider specification in java.security.
# There is a default provider that comes standard with the JDK. It
# is called the "SUN" provider, and its Provider subclass
# named Sun appears in the sun.security.provider package. Thus, the
# "SUN" provider is registered via the following:
#
#    security.provider.1=sun.security.provider.Sun
#
# (The number 1 is used for the default provider.)
#
# Note: Providers can be dynamically registered instead by calls to
# either the addProvider or insertProviderAt method in the Security
# class.

#
# List of providers and their preference orders (see above):
#

security.provider.1=sun.security.pkcs11.SunPKCS11 \
    ${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC

# Rest of file deleted