SunPKCS11
ProviderSUN
ProviderSunRsaSign
ProviderSunJSSE
ProviderSunJCE
ProviderSunJGSS
ProviderSunSASL
ProviderXMLDSig
ProviderSunPCSC
ProviderSunMSCAPI
ProviderSunEC
ProviderNote: The Standard Names Documentation contains more information about the standard names used in this document.
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 a solid understanding of this architecture.
This document describes the technical details of the providers shipped as part of Oracle's Java Environment.
getInstance("...", "SunJCE"); // not recommended vs. getInstance("..."); // recommendedOtherwise, applications are tied to specific providers that 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.
Due to import regulations in some countries, the Oracle implementation provides a default cryptographic jurisdiction policy file that limits the strength of cryptographic algorithms. Here are the maximum key sizes allowed by this "strong" version of the jurisdiction policy files:
Algorithm | Maximum Keysize |
---|---|
DES | 64 |
DESede | * |
RC2 | 128 |
RC4 | 128 |
RC5 | 128 |
RSA | * |
all others | 128 |
If stronger algorithms are needed (for example, AES with 256-bit keys), the JCE Unlimited Strength Jurisdiction Policy Files must be obtained and installed in the JDK/JRE.
It is the user's responsibility to verify that this action is permissible under local regulations.
SunPKCS11
ProviderThe 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.
SUN
ProviderJDK 1.1 introduced the Provider
architecture. The
first JDK provider was named SUN
, and contained two
types of cryptographic services (MessageDigest
s and
Signature
s). In later releases, other mechanisms were
added (SecureRandom
number generators,
KeyPairGenerator
s, KeyFactory
s, and so
on.).
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:
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator |
DSA |
AlgorithmParameters |
DSA |
CertificateFactory |
X.509 |
CertPathBuilder |
PKIX |
CertPathValidator |
PKIX |
CertStore |
Collection LDAP |
Configuration |
JavaLoginConfig |
KeyFactory |
DSA |
KeyPairGenerator |
DSA |
KeyStore |
JKS |
MessageDigest |
MD2 MD5 SHA-1 SHA-256 SHA-384 SHA-512 |
Policy |
JavaPolicy |
SecureRandom |
SHA1PRNG |
Signature |
NONEwithDSA SHA1withDSA |
The SUN
provider uses the following default
keysizes (in bits) and enforces 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
ImplementationsAdditional details on the SUN
provider
implementations for CertificateFactory
,
CertPathBuilder
, CertPathValidator
and
CertStore
are documented in Appendix B of the PKI
Programmer's Guide.
SunRsaSign
ProviderThe 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:
Engine | Algorithm Names |
---|---|
KeyFactory |
RSA |
KeyPairGenerator |
RSA |
Signature |
MD2withRSA MD5withRSA SHA1withRSA SHA256withRSA SHA384withRSA SHA512withRSA |
The SunRsaSign
provider uses the following default
keysize (in bits) and enforces the following restriction:
KeyPairGenerator
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
RSA | 1024 | Keysize must range between 512 and 65536 bits, the latter of which is unnecessarily large. |
SunJSSE
ProviderThe 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.n and
1.3.n. 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 later should request instances
of the SunRsaSign
provider instead. For backward
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:
Engine | Algorithm Name(s) |
---|---|
KeyFactory |
|
KeyManagerFactory |
|
KeyPairGenerator |
|
KeyStore |
|
Signature |
|
SSLContext |
|
TrustManagerFactory |
|
The SunJSSE
supports the following
protocol
parameters:
Protocol | Enabled by Default for Client | Enabled by Default for Server |
---|---|---|
SSLv3 | Yes | Yes |
TLSv1 | Yes | Yes |
TLSv1.1 | No | Yes |
TLSv1.2 | No | Yes |
SSLv2Hello | No | No |
Although SunJSSE
in the Java SE 7 release supports
TLS 1.1 and TLS 1.2, neither version is enabled by default for
client connections. Some servers do not implement forward
compatibility correctly and refuse to talk to TLS 1.1 or TLS 1.2
clients. For interoperability, SunJSSE
does not enable
TLS 1.1 or TLS 1.2 by default for client connections.
Server connections have no such interoperability problem. TLS 1.1 and TLS 1.2 are enabled by default for server connections.
The SSLv3, TLSv1, and TLSv1.1 protocols allow you to send SSLv3, TLSv1, and TLSv1.1 hellos encapsulated in an SSLv2 format hello. In the Java SE 7 release, this support is still present but is disabled by default.
SunJSSE
supports a large number of cipher suites.
The two tables that follow show the cipher suites supported by
SunJSSE in preference order and the release in which they were
introduced.
The first table lists the cipher suites that are enable by default. The second table shows cipher suites that are supported by SunJSSE but disabled by default.
Cipher Suite | J2SE v1.4 | J2SE v1.4.1, v1.4.2 | J2SE 5.0 | Java SE 6 | Java SE 7 |
---|---|---|---|---|---|
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
X1 | ||||
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
X1 | ||||
TLS_RSA_WITH_AES_256_CBC_SHA256 |
X1 | ||||
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
X1 | ||||
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
X1 | ||||
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
X1 | ||||
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
X1 | ||||
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
X | X | |||
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
X | X | |||
TLS_RSA_WITH_AES_256_CBC_SHA |
X | X | X | X | |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
X | X | |||
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
X | X | |||
TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
X | X | X | X | |
TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
X | X | X | X | |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_RSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
X1 | ||||
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
X | X | |||
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
X | X | |||
TLS_RSA_WITH_AES_128_CBC_SHA |
X | X | X | X | |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
X | X | |||
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
X | X | |||
TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
X | X | X | X | |
TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
X | X | X | X | |
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA |
X | X | |||
TLS_ECDHE_RSA_WITH_RC4_128_SHA |
X | X | |||
SSL_RSA_WITH_RC4_128_SHA |
X | X | X | X | X |
TLS_ECDH_ECDSA_WITH_RC4_128_SHA |
X | X | |||
TLS_ECDH_RSA_WITH_RC4_128_SHA |
X | X | |||
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA |
X | X | |||
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA |
X | X | |||
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
X | X | X | X | X |
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA |
X | X | |||
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA |
X | X | |||
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA |
X | X | X | X | |
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
X | X | X | X | X |
SSL_RSA_WITH_RC4_128_MD5 |
X | X | X | X | X |
TLS_EMPTY_RENEGOTIATION_INFO_SCSV 2 |
1.4.2u28+ | u26+ | u22+ | X |
1 Cipher suites with SHA384 and SHA256 are available only for TLS 1.2 or later.
2
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
is a new
pseudo-cipher suite to support RFC 5746. See the Transport
Layer Security (TLS) Renegotiation Issue section of the JSEE
Reference Guide for more information.
Cipher Suite | J2SE v1.4 | J2SE v1.4.1, v1.4.2 | J2SE 5.0 | Java SE 6 | Java SE 7 |
---|---|---|---|---|---|
TLS_DH_anon_WITH_AES_256_CBC_SHA256 |
X | ||||
TLS_ECDH_anon_WITH_AES_256_CBC_SHA |
X | X | |||
TLS_DH_anon_WITH_AES_256_CBC_SHA |
X | X | X | X | |
TLS_DH_anon_WITH_AES_128_CBC_SHA256 |
X | ||||
TLS_ECDH_anon_WITH_AES_128_CBC_SHA |
X | X | |||
TLS_DH_anon_WITH_AES_128_CBC_SHA |
X | X | X | X | |
TLS_ECDH_anon_WITH_RC4_128_SHA |
X | X | |||
SSL_DH_anon_WITH_RC4_128_MD5 |
X | X | X | X | X |
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA |
X | X | |||
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA |
X | X | X | X | X |
TLS_RSA_WITH_NULL_SHA256 |
X | ||||
TLS_ECDHE_ECDSA_WITH_NULL_SHA |
X | X | |||
TLS_ECDHE_RSA_WITH_NULL_SHA |
X | X | |||
SSL_RSA_WITH_NULL_SHA |
X | X | X | X | X |
TLS_ECDH_ECDSA_WITH_NULL_SHA |
X | X | |||
TLS_ECDH_RSA_WITH_NULL_SHA |
X | X | |||
TLS_ECDH_anon_WITH_NULL_SHA |
X | X | |||
SSL_RSA_WITH_NULL_MD5 |
X | X | X | X | X |
SSL_RSA_WITH_DES_CBC_SHA |
X | X | X | X | X1 |
SSL_DHE_RSA_WITH_DES_CBC_SHA |
X | X | X | X1 | |
SSL_DHE_DSS_WITH_DES_CBC_SHA |
X | X | X | X | X1 |
SSL_DH_anon_WITH_DES_CBC_SHA |
X | X | X | X | X1 |
SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
X | X | X | X | X2 |
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 |
X | X | X | X | X2 |
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA |
X | X | X | X2 | |
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA |
X | X | X | X2 | |
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA |
X | X | X | X | X2 |
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA |
X | X | X | X | X2 |
TLS_KRB5_WITH_RC4_128_SHA |
X | X | X | ||
TLS_KRB5_WITH_RC4_128_MD5 |
X | X | X | ||
TLS_KRB5_WITH_3DES_EDE_CBC_SHA |
X | X | X | ||
TLS_KRB5_WITH_3DES_EDE_CBC_MD5 |
X | X | X | ||
TLS_KRB5_WITH_DES_CBC_SHA |
X | X | X1 | ||
TLS_KRB5_WITH_DES_CBC_MD5 |
X | X | X1 | ||
TLS_KRB5_EXPORT_WITH_RC4_40_SHA |
X | X | X2 | ||
TLS_KRB5_EXPORT_WITH_RC4_40_MD5 |
X | X | X2 | ||
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA |
X | X | X2 | ||
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 |
X | X | X2 |
1 RFC 5246 TLS 1.2 forbids the use of these suites. These can be used in the SSLv3/TLS1.0/TLS1.1 protocols, but cannot be used in TLS 1.2 and later.
2 RFC 4346 TLS 1.1 forbids the use of these suites. These can be used in the SSLv3/TLS1.0 protocols, but cannot be used in TLS 1.1 and later.
Cipher suites that use AES_256 require installation of the JCE Unlimited Strength Jurisdiction Policy Files. See Import Limits on Cryptographic Algorithms.
Cipher suites that use Elliptic Curve Cryptography (ECDSA, ECDH, ECDHE, ECDH_anon) require a JCE cryptographic provider that meets the following requirements:
The provider must implement 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".
The provider must support 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 cipher suites to
be used.
The provider must 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, that is, using an object identifier.
If these requirements are not met, EC cipher suites may not be negotiated correctly.
Prior to the Java SE 7 release, the SSL/TLS implementation did
not check the version number in PreMasterSecret, and the SSL/TLS
client did not send the correct version number by default. Unless
the system property
com.sun.net.ssl.rsaPreMasterSecretFix
is set to
true
, the TLS client sends the active negotiated
version, but not the expected maximum version supported by the
client.
For compatibility, this behavior is preserved for SSL version
3.0 and TLS version 1.0. However, for TLS version 1.1 or later, the
implementation tightens checking the PreMasterSecret version
numbers as required by RFC 5246. Clients always
send the correct version number, and servers check the version
number strictly. The system property,
com.sun.net.ssl.rsaPreMasterSecretFix
, is not used in
TLS 1.1 or later.
SunJCE
ProviderAs 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:
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator |
DiffieHellman |
AlgorithmParameters |
AES Blowfish DES DESede DiffieHellman OAEP PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 RC2 |
Cipher |
See the Cipher table. |
KeyAgreement |
DiffieHellman |
KeyFactory |
DiffieHellman |
KeyGenerator |
AES ARCFOUR Blowfish DES DESede HmacMD5 HmacSHA1 HmacSHA256 HmacSHA384 HmacSHA512 RC2 |
KeyPairGenerator |
DiffieHellman |
KeyStore |
JCEKS |
Mac |
HmacMD5 HmacSHA1 HmacSHA256 HmacSHA384 HmacSHA512 |
SecretKeyFactory |
DES DESede PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 PBKDF2WithHmacSHA1 |
The following table lists cipher algorithms available in the SunJCE provider.
Algorithm Name | Modes | Paddings |
---|---|---|
AES | ECB, CBC, PCBC, CTR, CTS, CFB, CFB8..CFB128, OFB, OFB8..OFB128 | NOPADDING, PKCS5PADDING, ISO10126PADDING |
AESWrap | ECB | NOPADDING |
ARCFOUR | ECB | NOPADDING |
Blowfish, DES, DESede, RC2 | ECB, CBC, PCBC, CTR, CTS, CFB, CFB8..CFB64, OFB, OFB8..OFB64 | NOPADDING, PKCS5PADDING, ISO10126PADDING |
DESedeWrap | CBC | NOPADDING |
PBEWithMD5AndDES, PBEWithMD5AndTripleDES1 PBEWithSHA1AndDESede, PBEWithSHA1AndRC2_40 | CBC | PKCS5Padding |
RSA | ECB | NOPADDING, PKCS1PADDING, OAEPWITHMD5ANDMGF1PADDING, OAEPWITHSHA1ANDMGF1PADDING, OAEPWITHSHA-1ANDMGF1PADDING, OAEPWITHSHA-256ANDMGF1PADDING, OAEPWITHSHA-384ANDMGF1PADDING, OAEPWITHSHA-512ANDMGF1PADDING |
1 PBEWithMD5AndTripleDES is a proprietary algorithm that has not been standardized.
The SunJCE provider uses the following default keysizes (in bits) and enforces the following restrictions:
KeyGenerator
Algorithm 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
Algorithm 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). |
SunJGSS
ProviderThe following algorithms are available in the
SunJGSS
provider:
OID | Name |
---|---|
1.2.840.113554.1.2.2 |
Kerberos v5 |
1.3.6.1.5.5.2 |
SPNEGO |
SunSASL
ProviderThe following algorithms are available in the
SunSASL
provider:
Engine | Algorithm Names |
---|---|
SaslClient |
CRAM-MD5 DIGEST-MD5 EXTERNAL GSSAPI PLAIN |
SaslServer |
CRAM-MD5 DIGEST-MD5 GSSAPI |
XMLDSig
ProviderThe following algorithms are available in the
XMLDSig
provider:
Engine | Algorithm Names |
---|---|
KeyInfoFactory |
DOM |
TransformService |
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 -
(CanonicalizationMethod.INCLUSIVE )http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments - ( CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS )http://www.w3.org/2001/10/xml-exc-c14n# - ( CanonicalizationMethod.EXCLUSIVE )http://www.w3.org/2001/10/xml-exc-c14n#WithComments - ( CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS )http://www.w3.org/2000/09/xmldsig#base64 - ( Transform.BASE64 )http://www.w3.org/2000/09/xmldsig#enveloped-signature - ( Transform.ENVELOPED )http://www.w3.org/TR/1999/REC-xpath-19991116 - ( Transform.XPATH )http://www.w3.org/2002/06/xmldsig-filter2 - ( Transform.XPATH2 )http://www.w3.org/TR/1999/REC-xslt-19991116 - ( Transform.XSLT ) |
XMLSignatureFactory |
DOM |
SunPCSC
ProviderThe 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:
Engine | Algorithm Names |
---|---|
TerminalFactory |
PC/SC |
SunMSCAPI
ProviderThe 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:
Engine | Algorithm Names |
---|---|
Cipher |
RSA RSA/ECB/PKCS1Padding only |
KeyPairGenerator |
RSA |
KeyStore |
Windows-MY The keystore type that identifies the native Microsoft Windows MY keystore. It contains the user's personal certificates and associated private keys. Windows-ROOTThe keystore type that identifies the native Microsoft Windows ROOT keystore. It contains the certificates of Root certificate authorities and other self-signed trusted certificates. |
SecureRandom |
Windows-PRNG
The name of the native pseudo-random number generation (PRNG) algorithm. |
Signature |
MD2withRSA MD5withRSA SHA1withRSA |
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). |
SunEC
ProviderThe SunEC provider implements Elliptical Curve Cryptography (ECC). ECC is emerging as an attractive public-key cryptosystem for mobile/wireless and other environments. Compared to traditional cryptosystems like RSA, ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, as well as memory and bandwidth savings.
Applications can now use the standard JCA/JCE APIs to access ECC functionality without the dependency on external ECC libraries(via SunPKCS11), as was the case in the JDK 6 release.
The following algorithms are available in the SunEC
provider:
Engine | Algorithm Name(s) |
---|---|
AlgorithmParameters |
EC |
KeyAgreement |
ECDH |
KeyFactory |
EC |
KeyPairGenerator |
EC |
Signature |
NONEwithECDSA SHA1withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA |
The SunEC provider uses the following default keysizes (in bits) and enforces the following restrictions:
KeyPairGenerator
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
EC | 256 | Keysize must range from 112 to 571 (inclusive). |