• Oracle Technology Network
• Software Downloads
• Documentation

Search

The following topics are covered:

• Introduction
• Import Limits on Cryptographic Algorithms
• Cipher Transformations
• TheSunPKCS11 Provider
• TheSUN Provider
• TheSunRsaSign Provider
• TheSunJSSE Provider
• TheSunJCE Provider
• TheSunJGSS Provider
• TheSunSASL Provider
• TheXMLDSig Provider
• TheSunPCSC Provider
• TheSunMSCAPI Provider
• TheSunEC Provider
• TheOracleUcrypto Provider
• The Apple Provider

Note: TheStandard NamesDocumentation contains more information about the standardnames used in this document.

Introduction

The Java platform defines a set of APIs spanning major securityareas, including cryptography, public key infrastructure,authentication, secure communication, and access control. TheseAPIs allow developers to easily integrate security mechanisms intotheir application code. TheJavaCryptography Architecture (JCA) and itsProvider Architecture isa core concept of the Java Development Kit (JDK). It is assumedreaders have a solid understanding of this architecture.

This document describes the technical details of the providersshipped as part of Oracle's Java Environment.

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

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

Otherwise, applications are tied to specific providers that may notbe available on other Java implementations. They also might not beable to take advantage of available optimized providers (forexample, hardware accelerators via PKCS11 or native OSimplementations such as Microsoft's MSCAPI) that have a higherpreference order than the specific requested provider.

Import Limits on Cryptographic Algorithms

By default, an application can use cryptographic algorithms of any strength.However, due to import regulations in some locations, you may have to limit thestrength of those algorithms. The JDK provides two different sets of jurisdictionpolicy files, "limited" and "unlimited", in the directory<java-home>/jre/lib/security/policythat determine the strength of cryptographic algorithms. Information aboutjurisdiction policy files and how to activate them is available inAppendix C: Cryptographic Strength Configuration.

Consult your export/import control counsel or attorney to determine the exactrequirements for your location.

For the "limited" configuration, the following table lists the maximum key sizesallowed by the "limited" set of jurisdiction policy files:

Cipher Transformations

Thejavax.crypto.Cipher.getInstance(String transformation) factory method generatesCiphers using transformations of the formalgorithm/mode/padding. If the mode/padding are omitted, the SunJCE and SunPKCS11 providers use ECB as the default mode and PKCS5Padding as the default padding for many symmetric ciphers.

It is recommended to use transformations that fully specify the algorithm, mode, and padding instead of relying on the defaults.

Note: ECB works well for single blocks of data and can beparallelized, but absolutely should not be used for multiple blocks of data.

TheSunPKCS11 Provider

The Cryptographic Token Interface Standard (PKCS#11) providesnative programming interfaces to cryptographic mechanisms, such ashardware cryptographic accelerators and Smart Cards. When properlyconfigured, theSunPKCS11 provider enablesapplications to use the standard JCA/JCE APIs to access nativePKCS#11 libraries.TheSunPKCS11 provider itselfdoes not contain cryptographic functionality, it is simply aconduit between the Java environment and the native PKCS11providers. TheJava PKCS#11 ReferenceGuide has a much more detailed treatment of this provider.

TheSUN Provider

JDK 1.1 introduced theProvider architecture. Thefirst JDK provider was namedSUN, and contained twotypes of cryptographic services (MessageDigests andSignatures). In later releases, other mechanisms wereadded (SecureRandom number generators,KeyPairGenerators,KeyFactorys, and soon.).

United States export regulations in effect at the time placedsignificant restrictions on the type of cryptographic functionalitythat could be made available internationally in the JDK. For thisreason, theSUN provider has historically containedcryptographic engines that did not directly encrypt or decryptdata.

The following algorithms are available in theSUNprovider:

Keysize Restrictions

TheSUN provider uses the following defaultkeysizes (in bits) and enforces the following restrictions:

KeyPairGenerator

AlgorithmParameterGenerator

CertificateFactory/CertPathBuilder/CertPathValidator/CertStoreImplementations

Additional details on theSUN providerimplementations forCertificateFactory,CertPathBuilder,CertPathValidator andCertStore are documented inAppendix B of the PKIProgrammer's Guide.

TheSunRsaSign Provider

TheSunRsaSign provider was introduced in JDK 1.3as an enhanced replacement for the RSA signatures in theSunJSSE provider.

The following algorithms are available in theSunRsaSign provider:

Keysize Restrictions

TheSunRsaSign provider uses the following defaultkeysize (in bits) and enforces the following restriction:

KeyPairGenerator

TheSunJSSE Provider

The Java Secure Socket Extension (JSSE) was originally releasedas a separate "Optional Package" (also briefly known as a "StandardExtension"), and was available for JDK 1.2.n and1.3.n. TheSunJSSE provider was introduced aspart of this release.

In earlier JDK releases, there were no RSA signature providersavailable in the JDK, thereforeSunJSSE had to provideits own RSA implementation in order to use commonly availableRSA-based certificates. JDK 5 introduced theSunRsaSign provider, which provides all thefunctionality (and more) of theSunJSSE provider.Applications targeted at JDK 5.0 and later should request instancesof theSunRsaSign provider instead. For backwardcompatibility, the RSA algorithms are still available through thisprovider, but are actually implemented in theSunRsaSign provider.

Algorithms

The following algorithms are available in theSunJSSE provider:

Footnote 1 The PKCS12KeyStore implementation does not support theKeyBag type.

Protocols

TheSunJSSE supports the followingprotocol parameters:

Footnote 1SSLv3 was disabled by default since Java SE 7u75.

Footnote 2AlthoughSunJSSE in the Java SE 7release supports TLS 1.1 and TLS 1.2, neither version is enabled bydefault for client connections. Some servers do not implementforward compatibility correctly and refuse to talk to TLS 1.1 orTLS 1.2 clients. For interoperability,SunJSSE doesnot enable TLS 1.1 or TLS 1.2 by default for clientconnections.

Server connections have no such interoperability problem. TLS1.1 and TLS 1.2 are enabled by default for server connections.

Footnote 3The SSLv3, TLSv1, and TLSv1.1 protocols allowyou to send SSLv3, TLSv1, and TLSv1.1 hellos encapsulated in anSSLv2 format hello.

Cipher Suites

SunJSSE supports a large number of cipher suites.The two tables that follow show the cipher suites supported bySunJSSE in preference order and the release in which they wereintroduced.

The first table lists the cipher suites that are enable bydefault. The second table shows cipher suites that are supported bySunJSSE but disabled by default.

Footnote 1Cipher suites with SHA384 and SHA256 are available only for TLS 1.2or later.

Footnote 2TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a newpseudo-cipher suite to support RFC 5746. See theTransportLayer Security (TLS) Renegotiation Issue section of the JSEEReference Guide for more information.

Footnote 1RFC 5246 TLS 1.2forbids the use of these suites. These can be used in theSSLv3/TLS1.0/TLS1.1 protocols, but cannot be used in TLS 1.2 andlater.

Footnote 2RFC 4346 TLS 1.1forbids the use of these suites. These can be used in theSSLv3/TLS1.0 protocols, but cannot be used in TLS 1.1 andlater.

Cipher suites that use AES_256 require installation of the JCEUnlimited Strength Jurisdiction Policy Files. SeeImport Limits on Cryptographic Algorithms.

Cipher suites that use Elliptic Curve Cryptography (ECDSA, ECDH,ECDHE, ECDH_anon) require a JCE cryptographic provider that meetsthe following requirements:

• The provider must implement ECC as defined by the classes andinterfaces in the packagesjava.security.spec andjava.security.interfaces. ThegetAlgorithm() method of elliptic curve key objectsmust return the string "EC".

• The provider must support theSignature algorithmsSHA1withECDSA and NONEwithECDSA, theKeyAgreementalgorithm ECDH, and aKeyPairGenerator and aKeyFactory for algorithm EC. If one of thesealgorithms is missing, SunJSSE will not allow EC cipher suites tobe used.

• The provider must support all the SECG curves referenced inRFC 4492specification, section 5.1.1 (see also appendix A). Incertificates, points should be encoded using the uncompressed formand curves should be encoded using thenamedCurvechoice, that is, using an object identifier.

If these requirements are not met, EC cipher suites may not benegotiated correctly.

Tighter Checking of EncryptedPreMasterSecret Version Numbers

Prior to the Java SE 7 release, the SSL/TLS implementation didnot check the version number in PreMasterSecret, and the SSL/TLSclient did not send the correct version number by default. Unlessthe system propertycom.sun.net.ssl.rsaPreMasterSecretFix is set totrue, the TLS client sends the active negotiatedversion, but not the expected maximum version supported by theclient.

For compatibility, this behavior is preserved for SSL version3.0 and TLS version 1.0. However, for TLS version 1.1 or later, theimplementation tightens checking the PreMasterSecret versionnumbers as required byRFC 5246. Clients alwayssend the correct version number, and servers check the versionnumber strictly. The system property,com.sun.net.ssl.rsaPreMasterSecretFix, is not used inTLS 1.1 or later.

TheSunJCE Provider

As described briefly inTheSUN Provider, US export regulations at the timerestricted the type of cryptographic functionality that could bemade available in the JDK. A separate API and referenceimplementation was developed that allowed applications toencrypt/decrypt data. The Java Cryptographic Extension (JCE) wasreleased 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 enoughthat JCE (and SunJSSE) could be bundled as part of the JDK.

The following algorithms are available in the SunJCEprovider:

The following table listscipher algorithms available in the SunJCE provider.

¹ PBEWithMD5AndTripleDES is a proprietaryalgorithm that has not been standardized.

Keysize Restrictions

The SunJCE provider uses the following default keysizes (inbits) and enforces the following restrictions:

KeyGenerator

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

KeyPairGenerator

AlgorithmParameterGenerator

Footnote 1Diffie-Hellman key pair generation supports key sizes up to 2048 bits since Java SE 7u91. Prior to Java SE 7u91, the default key size was 1024.

TheSunJGSS Provider

The following algorithms are available in theSunJGSS provider:

TheSunSASL Provider

The following algorithms are available in theSunSASL provider:

TheXMLDSig Provider

The following algorithms are available in theXMLDSig provider:

TheSunPCSC Provider

The SunPCSC provider enables applications to use theJava Smart Card I/OAPI to interact with the PC/SC Smart Card stack of theunderlying operating system. On some operating systems, it may benecessary to enable and configure the PC/SC stack before it isusable. Consult your operating system documentation fordetails.

On Solaris and Linux platforms, SunPCSC accesses the PC/SC stackvia thelibpcsclite.so library. It looks for thislibrary in the directories/usr/$LIBISA and/usr/local/$LIBISA, where$LIBISA isexpanded tolib on 32-bit platforms,lib/64 on 64-bit Solaris platforms, andlib64 on 64-bit Linux platforms. The system propertysun.security.smartcardio.library may also be set tothe full filename of an alternatelibpcsclite.soimplementation. On Windows platforms, SunPCSC always calls intowinscard.dll and no Java-level configuration isnecessary or possible.

If PC/SC is available on the host platform, the SunPCSCimplementation can be obtained viaTerminalFactory.getDefault() andTerminalFactory.getInstance("PC/SC"). If PC/SC is notavailable or not correctly configured, agetInstance()call will fail with aNoSuchAlgorithmException andgetDefault() will return a JRE built-in implementationthat does not support any terminals.

The following algorithms are available in theSunPCSC provider:

TheSunMSCAPI Provider

The SunMSCAPI provider enables applications to use the standardJCA/JCE APIs to access the native cryptographic libraries,certificates stores and key containers on the Microsoft Windowsplatform. The SunMSCAPI provider itself does not containcryptographic functionality, it is simply a conduit between theJava environment and the native cryptographic services onWindows.

The following algorithms are available in theSunMSCAPI provider:

Keysize Restrictions

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

KeyGenerator

TheSunEC Provider

The SunEC provider implements Elliptical Curve Cryptography(ECC). ECC is emerging as an attractive public-key cryptosystem formobile/wireless and other environments. Compared to traditionalcryptosystems like RSA, ECC offers equivalent security with smallerkey sizes, which results in faster computations, lower powerconsumption, as well as memory and bandwidth savings.

Applications can now use the standard JCA/JCE APIs to access ECCfunctionality without the dependency on external ECC libraries(viaSunPKCS11), as was the case in the JDK 6 release.

The following algorithms are available in theSunECprovider:

Keysize Restrictions

The SunEC provider uses the following default keysizes (in bits)and enforces the following restrictions:

KeyPairGenerator

TheOracleUcrypto Provider

The Solaris-only security providerOracleUcrypto (introduced in JDK 7u4) leverages the Solaris Ucrypto library to offload and delegate cryptographic operations supported by the Oracle SPARC T4 basedon-core cryptographic instructions. TheOracleUcryptoprovider itself does not contain cryptographic functionality; it issimply a conduit between the Java environment and the SolarisUcrypto library.

If the underlying Solaris Ucrypto library does not support aparticular algorithm, then the OracleUcrypto provider will notsupport it either. Consequently, at runtime, the supportedalgorithms consists of the intersection of those that the SolarisUcrypto library supports and those that theOracleUcrypto provider recognizes.

Note that theOracleUcrypto provider is includedonly in Oracle's JDK. It is not part of OpenJDK.

The following algorithms are available in theOracleUcrypto provider:

Keysize Restrictions

TheOracleUcrypto provider does not specify anydefault keysizes or keysize restrictions; these are specified bythe underlying Solaris Ucrypto library.

OracleUcrypto Provider Configuration File

TheOracleUcrypto provider has a configuration filenameducrypto-solaris.cfg that resides in the$JAVA_HOME/lib/security directory. Modify thisconfiguration file to specify which algorithms to disable bydefault. For example, the following configuration file disables AESwith CFB128 mode by default:

## Configuration file for the OracleUcrypto provider#disabledServices = {  Cipher.AES/CFB128/PKCS5Padding  Cipher.AES/CFB128/NoPadding}

The Apple Provider

TheApple provider implements ajava.security.KeyStore that provides access to the Mac OS X Keychain.

The following algorithms are available in theApple provider: