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

Note: The Standard Names Documentation contains more information about the standard names used in this document.

Introduction

The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code. The Java Cryptography Architecture (JCA) and its Provider Architecture is a core concept of the Java Development Kit (JDK). It is assumed readers have an solid understanding of this architecture.

This document describes the technical details of the providers shipped as part of Sun's Java Environment.

---

Reminder: Cryptographic implementations in the Sun JDK are distributed through several different providers ("Sun", "SunJSSE", "SunJCE", "SunRsaSign") for both historical reasons and by the types of services provided. General purpose applications SHOULD NOT request cryptographic services from specific providers. That is:

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

Otherwise, applications are tied to specific providers which may not be available on other Java implementations. They also might not be able to take advantage of available optimized providers (for example, hardware accelerators via PKCS11 or native OS implementations such as Microsoft's MSCAPI) that have a higher preference order than the specific requested provider.

---

The SunPKCS11 Provider

The Cryptographic Token Interface Standard ( PKCS#11) provides native programming interfaces to cryptographic mechanisms, such as hardware cryptographic accelerators and Smart Cards. When properly configured, the SunPKCS11 provider enables applications to use the standard JCA/JCE APIs to access native PKCS#11 libraries. The SunPKCS11 provider itself does not contain cryptographic functionality, it is simply a conduit between the Java environment and the native PKCS11 providers. The Java PKCS#11 Reference Guide has a much more detailed treatment of this provider.

The SUN Provider

JDK 1.1 introduced the Provider architecture. The first JDK provider was named SUN, and contained two types of cryptographic services (MessageDigests and Signatures). In later releases, other mechanisms were added (SecureRandom number generators, KeyPairGenerators, KeyFactorys, etc.).

United States export regulations in effect at the time placed significant restrictions on the type of cryptographic functionality that could be made available internationally in the JDK. For this reason, the SUN provider has historically contained cryptographic engines that did not directly encrypt or decrypt data.

The following algorithms are available in the SUN provider:

Keysize Restrictions

The SUN provider uses the following default keysizes (in bits) and enforce the following restrictions:

KeyPairGenerator

Alg. Name	Default Keysize	Restrictions/Comments
DSA	1024	Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive).

AlgorithmParameterGenerator

Alg. Name	Default Keysize	Restrictions/Comments
DSA	1024	Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive).

CertificateFactory/CertPathBuilder/ CertPathValidator/CertStore implementations

Additional details on the SUN provider implementations for CertificateFactory, CertPathBuilder, CertPathValidator and CertStore are documented in Appendix B of the PKI Programmer's Guide.

The SunRsaSign Provider

The SunRsaSign provider was introduced in JDK 1.3 as an enhanced replacement for the RSA signatures in the SunJSSE provider.

The following algorithms are available in the SunRsaSign provider:

Keysize Restrictions

The SunRsaSign provider uses the following default keysizes (in bits) and enforce the following restrictions:

KeyPairGenerator

Alg. Name	Default Keysize	Restrictions/Comments
RSA	1024	Keysize must range between 512 and 65536 bits, the former of which is unnecessarily large.

The SunJSSE Provider

The Java Secure Socket Extension (JSSE) was originally released as a separate "Optional Package" (also briefly known as a "Standard Extension"), and was available for JDK 1.2.x and 1.3.x. The SunJSSE provider was introduced as part of this release.

In earlier JDK releases, there were no RSA signature providers available in the JDK, therefore SunJSSE had to provide its own RSA implementation in order to use commonly available RSA-based certificates. JDK 5 introduced the SunRsaSign provider, which provides all the functionality (and more) of the SunJSSE provider. Applications targeted at JDK 5.0 and higher should request instances of the SunRsaSign provider instead. For backwards-compatibility, the RSA algorithms are still available through this provider, but are actually implemented in the SunRsaSign provider.

The following algorithms are available in the SunJSSE provider:

The SunJSSE also supports the following protocol parameters:

SunJSSE supports a large number of ciphersuites. The table below shows the ciphersuites supported by SunJSSE in their default preference order and the release in which they were introduced.

Cipher Suite	Supported In Releases
	<1.4.2	1.4.2	J2SE 5	Java SE 6
SSL_RSA_WITH_RC4_128_MD5	X	X	X	X
SSL_RSA_WITH_RC4_128_SHA	X	X	X	X
TLS_RSA_WITH_AES_128_CBC_SHA		X	X	X
TLS_RSA_WITH_AES_256_CBC_SHA		X	X	X
TLS_ECDH_ECDSA_WITH_RC4_128_SHA				X
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA				X
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA				X
TLS_ECDH_RSA_WITH_RC4_128_SHA				X
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA				X
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA				X
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA				X
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA				X
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA				X
TLS_ECDHE_RSA_WITH_RC4_128_SHA				X
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA				X
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA				X
TLS_DHE_RSA_WITH_AES_128_CBC_SHA		X	X	X
TLS_DHE_RSA_WITH_AES_256_CBC_SHA		X	X	X
TLS_DHE_DSS_WITH_AES_128_CBC_SHA		X	X	X
TLS_DHE_DSS_WITH_AES_256_CBC_SHA		X	X	X
SSL_RSA_WITH_3DES_EDE_CBC_SHA	X	X	X	X
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA				X
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA				X
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA				X
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA				X
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA		X	X	X
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA	X	X	X	X
SSL_RSA_WITH_DES_CBC_SHA	X	X	X	X
SSL_DHE_RSA_WITH_DES_CBC_SHA		X	X	X
SSL_DHE_DSS_WITH_DES_CBC_SHA	X	X	X	X
SSL_RSA_EXPORT_WITH_RC4_40_MD5	X	X	X	X
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA		X	X	X
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA		X	X	X
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA	X	X	X	X
SSL_RSA_WITH_NULL_MD5	X	X	X	X
SSL_RSA_WITH_NULL_SHA	X	X	X	X
TLS_ECDH_ECDSA_WITH_NULL_SHA				X
TLS_ECDH_RSA_WITH_NULL_SHA				X
TLS_ECDHE_ECDSA_WITH_NULL_SHA				X
TLS_ECDHE_RSA_WITH_NULL_SHA				X
SSL_DH_anon_WITH_RC4_128_MD5	X	X	X	X
TLS_DH_anon_WITH_AES_128_CBC_SHA		X	X	X
TLS_DH_anon_WITH_AES_256_CBC_SHA		X	X	X
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA	X	X	X	X
SSL_DH_anon_WITH_DES_CBC_SHA	X	X	X	X
TLS_ECDH_anon_WITH_RC4_128_SHA				X
TLS_ECDH_anon_WITH_AES_128_CBC_SHA				X
TLS_ECDH_anon_WITH_AES_256_CBC_SHA				X
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA				X
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5	X	X	X	X
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA	X	X	X	X
TLS_ECDH_anon_WITH_NULL_SHA				X
TLS_KRB5_WITH_RC4_128_SHA			X	X
TLS_KRB5_WITH_RC4_128_MD5			X	X
TLS_KRB5_WITH_3DES_EDE_CBC_SHA			X	X
TLS_KRB5_WITH_3DES_EDE_CBC_MD5			X	X
TLS_KRB5_WITH_DES_CBC_SHA			X	X
TLS_KRB5_WITH_DES_CBC_MD5			X	X
TLS_KRB5_EXPORT_WITH_RC4_40_SHA			X	X
TLS_KRB5_EXPORT_WITH_RC4_40_MD5			X	X
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA			X	X
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5			X	X

Ciphersuites that use AES_256 requires installation of the JCE Unlimited Strength Jurisdiction Policy Files. See Java SE Download Page.

Ciphersuites that use Elliptic Curve Cryptography (ECDSA, ECDH, ECDHE, ECDH_anon) require that a JCE crypto provider with the following properties be installed:

• implements ECC as defined by the classes and interfaces in the packages java.security.spec and java.security.interfaces. The getAlgorithm() method of elliptic curve key objects must return the String "EC"

• supports the Signature algorithms SHA1withECDSA and NONEwithECDSA, the KeyAgreement algorithm ECDH, and a KeyPairGenerator and a KeyFactory for algorithm EC. If one of these algorithms is missing, SunJSSE will not allow EC ciphersuites to be used.

• the crypto provider should support all the SECG curves referenced in RFC 4492 specification, section 5.1.1 (see also appendix A). In certificates, points should be encoded using the uncompressed form and curves should be encoded using the namedCurve choice, i.e. using an object identifier. If these requirements are not met, EC ciphersuites may not be negotiated correctly.

The SunJCE Provider

As described briefly in The SUN Provider, US export regulations at the time restricted the type of cryptographic functionality that could be made available in the JDK. A separate API and reference implementation was developed that allowed applications to encrypt/decrypt data. The Java Cryptographic Extension (JCE) was released as a separate "Optional Package" (also briefly known as a "Standard Extension"), and was available for JDK 1.2.x and 1.3.x. During the development of JDK 1.4, regulations were relaxed enough that JCE (and SunJSSE) could be bundled as part of the JDK.

The following algorithms are available in the SunJCE provider:

Keysize Restrictions

The SunJCE provider uses the following default keysizes (in bits) and enforce the following restrictions:

KeyGenerator

Alg. Name	Default Keysize	Restrictions/Comments
AES	128	Keysize must be equal to 128, 192, or 256.
ARCFOUR (RC4)	128	Keysize must range between 40 and 1024 (inclusive).
Blowfish	128	Keysize must be a multiple of 8, ranging from 32 to 448 (inclusive).
DES	56	Keysize must be equal to 56.
DESede (Triple DES)	168	Keysize must be equal to 112 or 168. A keysize of 112 will generate a Triple DES key with 2 intermediate keys, and a keysize of 168 will generate a Triple DES key with 3 intermediate keys. Due to the "Meet-In-The-Middle" problem, even though 112 or 168 bits of key material are used, the effective keysize is 80 or 112 bits respectively.
HmacMD5	512	No keysize restriction.
HmacSHA1	512	No keysize restriction.
HmacSHA256	256	No keysize restriction.
HmacSHA384	384	No keysize restriction.
HmacSHA512	512	No keysize restriction.
RC2	128	Keysize must range between 40 and 1024 (inclusive).

NOTE: The various Password-Based Encryption (PBE) algorithms use various algorithms to generate key data, and ultimately depends on the targeted Cipher algorithm. For example, "PBEWithMD5AndDES" will always generate 56-bit keys.

KeyPairGenerator

Alg. Name	Default Keysize	Restrictions/Comments
Diffie-Hellman (DH)	1024	Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive).

AlgorithmParameterGenerator

Alg. Name	Default Keysize	Restrictions/Comments
Diffie-Hellman (DH)	1024	Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive).
DSA	1024	Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive).

The SunJGSS Provider

The following algorithms are available in the SunJGSS provider:

The SunSASL Provider

The following algorithms are available in the SunSASL provider:

The XMLDSig Provider

The following algorithms are available in the XMLDSig provider:

The SunPCSC Provider

The SunPCSC provider enables applications to use the Java Smart Card I/O API to interact with the PC/SC Smart Card stack of the underlying operating system. On some operating systems, it may be necessary to enable and configure the PC/SC stack before it is usable. Consult your operating system documentation for details.

On Solaris and Linux platforms, SunPCSC accesses the PC/SC stack via the libpcsclite.so library. It looks for this library in the directories /usr/$LIBISA and /usr/local/$LIBISA, where $LIBISA is expanded to lib on 32-bit platforms, lib/64 on 64-bit Solaris platforms, and lib64 on 64-bit Linux platforms. The system property sun.security.smartcardio.library may also be set to the full filename of an alternate libpcsclite.so implementation. On Windows platforms, SunPCSC always calls into winscard.dll and no Java-level configuration is necessary or possible.

If PC/SC is available on the host platform, the SunPCSC implementation can be obtained via TerminalFactory.getDefault() and TerminalFactory.getInstance("PC/SC"). If PC/SC is not available or not correctly configured, a getInstance() call will fail with a NoSuchAlgorithmException and getDefault() will return a JRE built-in implementation that does not support any terminals.

The following algorithms are available in the SunPCSC provider:

The SunMSCAPI Provider

The SunMSCAPI provider enables applications to use the standard JCA/JCE APIs to access the native cryptographic libraries, certificates stores and key containers on the Microsoft Windows platform. The SunMSCAPI provider itself does not contain cryptographic functionality, it is simply a conduit between the Java environment and the native cryptographic services on Windows.

The following algorithms are available in the SunMSCAPI provider:

Keysize Restrictions

The SunMSCAPI provider uses the following default keysizes (in bits) and enforce the following restrictions:

KeyGenerator

Alg. Name	Default Keysize	Restrictions/Comments
RSA	1024	Keysize ranges from 384 bits to 16,384 bits (depending on the underlying Microsoft Windows cryptographic service provider).