IBM 64-bit SDK for Windows AMD64/EM64T architecture, Java 2 Technology Edition, Version 1.4.2
Security Guide
Note: Before using this information and the product
it supports, read the general information under Notices.
This edition of the User Guide applies to:
- iKeyman
- Java Authentication and Authorization Service (JAAS) v2.0
- IBM Java Certification Path (CertPath) v1.0 Provider
- IBM Java Cryptography Extension (JCE) Provider
- IBM Java Generic Security Service (JGSS) v1.0 Provider
- IBM Java Secure Socket Extension (JSSE) v1.0.3 Provider
- IBM JSSE 2 Provider
- IBM Java JCE FIPS Provider
- IBM Java JSSE FIPS Provider
and to all subsequent releases, modifications, and service refreshes, until
otherwise indicated in new editions.
(c) Copyright Sun Microsystems, Inc. 1997, 2003, 901 San Antonio Rd., Palo
Alto, CA 94303 USA. All rights reserved.
(c) Copyright International Business Machines Corporation, 1999, 2007.
All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
The security components described in this User Guide are shipped with the
SDK and are not extensions. They provide a wide range of security services
through standard Java APIs (except iKeyman). The security components contain
the IBM implementation of various security algorithms and mechanisms.
The IBM(R) SDK v1.4.2 also provides two FIPS 140-2 certified cryptographic modules,
IBMJSSEFIPS and IBMJCEFIPS. They are implemented as JSSE and JCE providers
respectively. Because they support FIPS-approved cryptographic algorithms
and TLS cipher suites (in IBMJSSEFIPS) only, applications that are written
using these two modules must comply with the FIPS 140-2 requirements.
The CertPath component provides PKIX-compliant certification path building
and validation.
The JGSS component provides a generic API that can be plugged in by different
security mechanisms. IBM JGSS uses Kerberos V5 as the default mechanism for
authentication and secure communication.
The JAAS component provides a means for principal-based authentication
and authorization
The JCE framework has two providers: IBMJCE is the pre-registered default
provider; IBMJCEFIPS is optional.
JSSE is the Java(TM) implementation of the SSL and TLS protocols. It
has three providers: IBMJSSE is the pre-registered default provider, IBMJSSE2
and IBMJSSEFIPS are optional.
The Java security configuration file does not
refer to the Sun provider. The IBM JCE provider has replaced the Sun provider.
The JCE supplies all the signature handling message digest algorithms that
were previously supplied by the Sun provider. It also supplies the IBM secure random
number generator, IBMSecureRandom, which is a real Random Number Generator.
SHA1PRNG is a Pseudo Random Number Generator and is supplied for code compatibility.
SHA1PRNG is not guaranteed to produce the same output as the SUN SHA1PRNG.
In the IBM SDK v1.4.1, the following options were added to the java.security.debug property to help you debug Java Cryptography Architecture (JCA)-related
problems:
- provider - displays each provider request and load,
provider add and provider remove. It also displays the related exception when
a provider load fails.
- algorithm - displays each algorithm request, which
provider has supplied the algorithm and the implementing class name.
- :stack - you can append this option to either of algorithm - or provider. When you
request an algorithm, a stack trace is displayed. Use this stack trace to
determine the code that has requested the algorithm. This option also prints
the stack trace for exceptions that are swallowed or converted.
- :thread - adds the thread id to all debug message
lines. You can use this option together with all the other debug options.
An example of a valid option string is "provider, algorithm:stack".
In this guide, you'll see a 'What's new' section for each component, even
though this platform was not available at the 1.4.0 and 1.4.1 levels. This
information is provided to help you with migration.
The IBM SDK v1.4.2 has been tested with the following default security providers:
- security.provider.1=com.ibm.jsse.IBMJSSEProvider
- security.provider.2=com.ibm.crypto.provider.IBMJCE
- security.provider.3=com.ibm.security.jgss.IBMJGSSProvider
- security.provider.4=com.ibm.security.cert.IBMCertPath
You can add other IBM security providers either statically or from within
your Java application's code. To add a new provider statically, edit a java
security properties file (for example, java.security). To add a new provider
from your application's code, use the methods of the java.security.Security
class (for example, java.security.Security.addProvider()).
You can also add the following IBM security providers:
- com.ibm.fips.jsse.IBMJSSEFIPSProvider
- com.ibm.crypto.fips.provider.IBMJCEFIPS
- com.ibm.jsse2.IBMJSSEProvider2
Notes:
- You can specify both jsse providers (IBMJSSE and IBMJSSE2) but you should
specify the original IBMJSSE provider, com.ibm.jsse.IBMJSSEProvider, first
for compatability reasons. Note that code written for the IBMJSSE Provider
might not compile or execute in exactly the same way for IBMJSSE2. For details,
see Differences between the IBMJSSE Provider and the IBMJSSE2 Provider.
- The IBMJSSE framework uses the original JSSE provider, IBMJSSE, so that,
if you invoke the method getDefault() on the classes SSLSocketFactory,
SSLServerSocketFactory and HttpsURLConnection, the com.ibm.jsse.IBMJSSEProvider
class will be used irrespective of the order in the provider. To ensure that
the getDefault() and getDefaultSSLSocketFactory() use the IBMJSSE2 Provider:
- Add the IBMJSSE2 provider before the IBMJSSE provider in the provider
list.
- Set the default SSLSocketFactory and SSLServerSocketFactory implementation
to be IBMJSSE2. That is, set the ssl.SocketFactory.provider security property to the value com.ibm.jsse2.SSLSocketFactoryImpl and the ssl.ServerSocketFactory.provider security
property to the value com.ibm.jsse2.SSLServerSocketFactoryImpl.
The iKeyman utility is a tool for managing your digital certificates. With
iKeyman, you can:
- Create a new key database or a test digital certificate
- Add CA roots to your database
- Copy certificates from one database to another
- Request and receive a digital certificate from a CA
- Set default keys, and change passwords
There are no changes in v1.4.2 over v1.4.1.
The following change was added in v1.4.1:
- An iKeyman wrapper that invokes the correct tool class was added.
The iKeyman User Guide is on the developerWorks(R) Web
site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The Sun Microsystems Java 2 platform provides a means to enforce
access controls based on where code came from and who signed it. These access controls are needed because
of the distributed nature of the Java platform where, for example, a remote
applet can be downloaded over a public network and then run locally.
However, before SDK v1.4.0, the Java 2 platform did not provide a way to
enforce similar access controls based on who runs the
code. To provide this type of access control, the Java 2 security architecture requires the
following:
- Additional support for authentication (determining who is actually running
the code)
- Extensions to the existing authorization components to enforce new access
controls based on who was authenticated
The Java Authentication and Authorization Service (JAAS) framework provides
these enhancements.
For a general overview of JAAS, see the Sun Web site: http://java.sun.com/products/jaas.
The IBM version of JAAS differs from the Sun version in the following way:
- The com.sun.* packages are reimplemented by IBM and renamed com.ibm.* packages.
-
IBM has added function to JAAS. See the Active Login section for more information about the added function.
There are no changes from the previous versions.
To use the JAAS APIs, see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The IBM version of JAAS for Windows(R) contains an additional function
called Active Login. Because Windows has an extensive security infrastructure,
it is important on servers to allow a Java program to log in as a particular Windows user and run with the underlying operating system knowing the
security identity on a particular thread. Without this extended support (speaking
strictly of Java Technology), JAAS would allow Java programs
to know who the user is. With this extended support, Java programs
can log in as different users and have non-Java programs (such as the Windows kernel) enforce security.
The following classes contain the additional support for Active Login:
- com.ibm.security.auth.NTThreadSubject
- This is the gateway to changing identities on an operating system thread
level.
- com.ibm.security.auth.module.Win64ActiveLoginModule
- This is specified in the login configuration file. If you construct a
LoginContext using a string name that calls this LoginModule, and you supply
a CallbackHandler that can supply a user ID and password suitable for this Windows computer, you can log in.
- com.ibm.security.auth.module.Win64ActiveSystem
-
This is an implementation class, largely hidden from users.
These classes are described in the JAAS APIs that are included with this
product.
To log in on Windows, an authorized program is required. The bin
subdirectory of the directory where the Runtime Environment is installed contains
a Windows service that can perform the login operation. To install the
service and start it:
- Make sure that you are logged in as an Administrator on the computer where
you want to install and start the service.
- Change directories to the bin directory.
- Type at a command prompt:
jaaslogon -install
To stop the service and remove it from the Service Manager autostart list:
- Change directories to the bin directory.
- Type at a command prompt:
jaaslogon -remove
Note: If you do not remove JAASLogon from the
Service Manager Autostart list and you uninstall the Runtime Environment,
you will get a "Failed Service" error on the Windows log on. To remove the error, remove
jaaslogon.exe from the Service Manager Autostart list.
The Java Certification Path API provides interfaces and abstract classes
for creating, building, and validating certification paths (also known as
"certificate chains").
The IBM CertPath classes differ from the Sun version in the following ways:
- The IBM CertPath provider is in the package com.ibm.security.cert.
- The IBM CertPath provider is called "IBMCertPath". Sun does
not have a separate provider for CertPath; CertPath is already supported by
the "SUN" provider.
- To enable CRL Distribution Points extension checking,
use the system property com.ibm.security.enableCRLDP. The system property
used by the Sun version is com.sun.security.enableCRLDP.
- When checking the certificate's CRL Distribution Points
extension, Sun's version retrieves the CRL only if the CRL location is specified
as an HTTP URL value inside the extension. The IBM provider recognizes both HTTP and LDAP
URLs.
The following changes were added in v1.4.2:
- The performance of the IBM CertPath provider has been improved.
- Limited support for the CRL Distribution Points extension has been added.
- IBM LDAP CertStore provides caching to cache lookups.
The following changes were added in v1.4.1 SR1:
- The trusted certificate that acts as TrustAnchor can be an X.509 v1 certificate.
- When you specify the certificate's subject or issuer name as a String
in X509CertSelector, the search for a matched certificate mechanism checks
only the name value and ignores the tag type.
There were no changes in v1.4.1 over v1.4.0.
The following changes were added in v1.4.0:
- Certificates from CertificatePair entry can be retrieved from LDAP type
certstore.
- The framework package name was changed from javax.security.cert to java.security.cert.
However, the old framework package is still supported.
For detailed information, including API documentation and samples, see
the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The Java Cryptography Extension (JCE) provides a framework and implementations
for encryption, key generation and key agreement, and Message Authentication
Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric,
block, and stream ciphers. The software also supports secure streams and
sealed objects. JCE supplements the Java 2 platform, which already includes
interfaces and implementations of message digests and digital signatures.
You can obtain unrestricted jurisdiction policy files from http://www.ibm.com/developerworks/java/jdk/security/index.html.
Note that the v1.4.1 unrestricted (and restricted) jurisdiction
policy files are not suitable for use with v1.4.2 and will cause security
exceptions.
The com.sun.* packages are reimplemented by IBM and renamed com.ibm.* packages.
The IBM version of JCE differs from the Sun version in the following ways:
- The com.sun.crypto.* packages are reimplemented by IBM and renamed
com.ibm.crypto.* packages.
- The IBM JCE provider replaces the Sun providers sun.security.provider.Sun,
com.sun.rsajca.Provider, and com.sun.crypto.provider.SunJCE.
- IBM provides more algorithms than Sun does:
- Cipher algorithms
- AES
- Blowfish
- DES
- Mars
- PBE with MD2 and DES
- PBE with MD2 and Triple DES
- PBE with MD2 and RC2
- PBE with MD5 and DES
- PBE with MD5 and Triple DES
- PBE with MD5 and RC2
- PBE with SHA1 and DES
- PBE with SHA1 and TripleDES
- PBE with SHA1 and RC2
- PBE with SHA1 and 40-bit RC2
- PBE with SHA1 and 128-bit RC2
- PBE with SHA1 and 40-bit RC4
- PBE with SHA1 and 128-bit RC4
- PBE with SHA1 and 2-key Triple DES
- PBE with SHA1 and 3-key Triple DES
- RC2
- RC4
- RSA encryption/decryption
- Seal
- Triple DES
- Signature algorithms
- SHA1 with RSA, MD5 with RSA, MD2 with RSA signatures
- SHA1 with DSA signature
- Message digest algorithms
- SHA1
- SHA2
- SHA3
- SHA5
- MD5
- MD2
- Message authentication code (MAC)
- Key agreement algorithm
- Random number generation algorithms
- IBMSecureRandom
- IBM SHA1PRNG
- Key Store
The following changes were made in v1.4.2:
- SHA2, SHA3 and SHA5 algorithms were added for hashing
- SHA1PRNG algorithm was added for generating pseudo random numbers
There were no changes in v1.4.1 from v1.4.0.
The following changes were made in v1.4.0:
- AES cipher algorithm has been added.
- Strong cryptography is the default, unlimited cryptography is available.
- Provider authentication of the JCE framework no longer required.
- JCE is now shipped with the Java SDK v1.4 on all platforms.
For detailed information, including API documentation and samples, see
the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The Java Generic Security Service (JGSS) API provides secure exchange of
messages between communicating applications.
The JGSS is an API framework that has Kerberos V5 as the underlying default
security mechanism. The API is a standardized abstract interface under which
you can plug different security mechanisms that are based on private-key,
public-key, and other security technologies. JGSS shields secure applications
from the complexities and peculiarities of the different underlying security
mechanisms. JGSS provides identity and message origin authentication, message
integrity, and message confidentiality. JGSS also features an optional Java Authentication and Authorization Service (JAAS) Kerberos login interface,
and authorization checks. JAAS augments the access control features of Java 2, which is based on CodeSource with access controls based on authenticated
principal identities.
The IBM version of JGSS differs from the Sun version in the following ways:
- The com.sun.* packages are reimplemented by IBM and renamed com.ibm.* packages.
- The format of the parameters passed to the Java tools kinit, ktab, and klist is different
from Sun's equivalent tools.
The following changes are added in v1.4.2:
- Configurable Kerberos Settings
- You can provide the name and realm settings for the Kerberos Key Distribution
Center (KDC) either from the Kerberos configuration file or by using the system
properties files java.security.krb5.kdc and java.security.krb5.realm. You
can also specify the boolean option refreshKrb5Config in
the entry for Krb5LoginModule in the JAAS configuration file. If you set this
option to true, the configuration values will be refreshed before
the login method of the Krb5LoginModule is called.
- Support for Slave Kerberos Key Distribution Center
- Kerberos uses slave KDCs so that, if the master KDC is unavailable,
the slave KDCs will respond to your requests. In previous releases, Kerberos
tried the master KDC only and would give up if there was no response within
the default KDC timeout.
- Support TCP for Kerberos Key Distribution Center Transport
- Kerberos uses UDP transport for ticket requests. In cases where Kerberos
tickets exceed the UDP packet size limit, Kerberos supports automatic fallback
to TCP. If a Kerberos ticket request using UDP fails and the KDC returns the
error code KRB_ERR_RESPONSE_TOO_BIG, TCP becomes the transport
protocol.
- Kerberos Service Ticket in the Subject's Private Credentials
- The Kerberos service ticket is stored in the Subject's private credentials.
This gives you access to the service ticket so that you can use it outside
the JGSS (for example, in native applications or for proprietary uses). In
addition, you can reuse the service ticket if the application tries to establish
a security context to the same service again. The service ticket should be
valid for it to be reusable.
The following change was added in v1.4.1:
- Wrappers have been added for the klist, kinit, and ktab Java tools. These wrappers invoke the relevant
tool classes so that you do not have to remember the full package name.
For detailed information about JGSS, including API documentation and samples,
see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The Java Secure Socket Extension (JSSE) is a Java package that enables secure Internet
communications. It implements a Java version of SSL (Secure Sockets Layer)
and TLS (Transport Layer Security) protocols and includes functions for data
encryption, server authentication, message integrity, and optional client
authentication.
By abstracting the complex underlying security algorithms and "handshaking"
mechanisms, JSSE minimizes the risk of creating subtle but dangerous security
vulnerabilities. Also, it simplifies application development by serving as
a building block that you can integrate directly into your applications. Using
JSSE, you can provide for the secure passage of data between a client and
a server running any application protocol (such as HTTP, Telnet, NNTP, and
FTP) over TCP/IP.
The IBM JSSE Provider default implementation does not allow anonymous ciphers.
However, you can override the default implementation by writing a TrustManager
class that allows anonymous ciphers.
The known differences between the IBM JSSE and Sun JSSE implementations are
described below. These differences do not affect either
the API specifications or the JSSE architecture.
- The IBM JSSE provider is called "com.ibm.jsse.IBMJSSEProvider".
- The IBM KeyManagerFactory is called "IbmX509".
- The IBM TrustManagerFactory is called "IbmX509".
- The IBM HTTPS protocol handler is called "com.ibm.net.ssl.www.protocol.Handler".
- Classes that are in the package com.sun.net.ssl in the Sun
implementation are in the com.ibm.net.ssl package in the IBM JSSE implementation.
- The IBM implementation supports the following protocols for
the engine class SSLContext, for the api setEnabledProtocols in the SSLSocket,
and for SSLServerSocket classes:
- SSL
- SSLv3
- SSLv2
- TLS
- TLSv1
- SSL_TLS
The IBM implementation does not support the "SSLv2Hello"
protocol. The IBM implementation supports the SSL v2 protocol. You can
use the IBM SSLContext getInstance() factory method to control which protocols
are enabled for an SSL connection. Using SSLContext's getInstance() or the
setEnabledProtocols() method provide the same result. With Sun's JSSE, the
protocol is controlled through setEnabledProtocols().
- The IBM JSSE framework allows the addition of other JSSE providers.
Sun's framework currently does not.
- The IBM JSSE implementation uses an internal cryptographic
provider.
- The IBM JSSE TrustManager does not allow anonymous ciphers.
To handshake with an anonymous cipher, a custom TrustManager that allows anonymous
ciphers must be provided.
- When a null KeyManager is passed to SSLContext, the IBM JSSE KeyManagerFactory
implemention will check system properties, then jssecacerts, if it exists,
and finally uses the cacerts file to find the key material. Sun's JSSE creates
an empty KeyManager.
- The IBM JSSE X509TrustManager and X509KeyManager throws an
exception if the TrustStore or KeyStore specified by the system properties
does not exist, if the password is incorrect, or if the keystore type is inappropriate
for the actual keystore. Sun's X509TrustManager creates a default TrustManager
or KeyManager with an empty keystore.
- The IBM JSSE requires that you have the trusted cert in your
Trusted Keystore. Sun's JSSE considers a certificate trusted if you have the
private key.
- The IBM JSSE implementation verifies the entire server or client
certificate chain, including trusted certificates. For example, if a trusted
certificate has expired, the handshake fails, even though the expired certificate
is trusted. Sun's JSSE verifies the certificate chain up to the trusted certificate.
Verification stops when it reaches a trusted certificate and the trusted
certificate and beyond are not verified.
- With the IBM JSSE implementation, tracing is turned on by javax.net.debug=true. Complete tracing requires the debug version of
IBMJSSE.
- The IBM JSSE implementation returns the same set of supported
ciphers for the methods getDefaultCiphersSuites and getSupportedCipherSuites.
Sun's JSSE getDefaultCipherSuites returns the list of cipher suites that
provide confidentiality protection and server authentication (that is, no
anonymous cipher suites). Sun's getEnabledCipherSuites returns the entire
list of cipher suites that Sun supports.
- For Sun's implementation, DSA server certificates can use
only *_DH*_* cipher suites. For the IBM implementation, if the server has a DSA
certificate only and only RSA* ciphers are enabled, the connection succeeds
with an RSA cipher. DSA will be used for authentication and ephemeral RSA
will be used for the key exchange.
- The IBM JSSE implementation does not support the new TrustManager
which implements rules for certificate chain path validation that Sun added
to v1.4.2. The new IBMJSSE2 Provider contains this support.
- The IBM SDK supports the NTLM authentication scheme.
To switch off NTLM authentication, set the system property com.ibm.NONTLM.
The following change takes effect from v1.4.2 Service Refresh
8:
- When IBM JSSE is used as a server, if the SSLv3 protocol is to be used for
the handshake, it will no longer agree to use any of the AES cipher suites.
Previously, the selection of the cipher suite was independent of the protocol
selected so you could do an old-style SSLv3 handshake with a more modern AES
cipher suite. The TLS protocol is not affected by this change. This change
was required to support Microsoft(R) Vista clients.
The following changes are added in v1.4.2:
There were no changes in v1.4.1 from v1.4.0.
The following changes were added in v1.4.0:
- Classes that were in com.ibm.net.ssl are now in javax.net.ssl. The SSLContext
class in com.ibm.net.ssl contained an init() method that is not supported
by the javax.net.ssl class. This additional method can be found in com.ibm.jsse.SSLContext.
- A number of API changes have been made to this release and are fully documented
in the Documentation.
For detailed information, including API documentation and samples, see
the developerWorks Web site, athttp://www.ibm.com/developerworks/java/jdk/security/index.html.
The IBMJSSE2 Provider is a new provider included with the SDK. It is not pre-registered in the java.security properties file
included with the SDK.
The IBMJSSE2 Provider has improved serviceability because the tracing and
debugging information that is supplied has been improved to assist with problem
determination. Also, the tracing is now configurable.
The IBMJSSE2 Provider uses the IBM JCE providers, IBMJCE, IBMJCEFIPS, and
IBMJCE4758 only. The IBMJSSE2 Provider cannot be configured to use another
JCE provider because of US government export regulations.
The IBMJSSE2 Provider does not contain cryptographic code because it uses
cryptographic support from the IBMJCEFIPS Provider. Therefore, IBMJSSE2 is
not required to be FIPS certified.
The IBMJSSE2 Provider, in addition to the simple X.509 based trustmanager
also supported by the IBMJSSE Provider, supports a second, PKIX-compliant
trust manager.
The IBMJSSE Provider and the IBMJSSE2 Provider differ in the following
way:
- The IBMJSSE2 Provider is called "com.ibm.jsse2.IBMJSSEProvider2". It is
not pre-registered in the provider list.
- The HTTPS protocol handler for the IBMJSSE2 Provider is called "com.ibm.net.ssl.www2.protocol.Handler".
- The IBMJSSE2 provider does not support the com.ibm.net.ssl framework.
Use the javax.net.ssl framework instead.
- The IBMJSSE2 Provider does not support the SSL version 2 protocol. It
supports the SSLv2Hello protocol.
- The AES_256 ciphers require the installation of the JCE Unlimited Strength
Jurisdiction Policy. The IBMJSSE Provider does not use JCE for its cryptographic
support and therefore does not require these files.
- The IBMJSSE2 Provider requires the IBMJCE.
- The IBMJSSE2 Provider considers a certificate trusted if you have the
private key.
- The HTTPS protocol handler for the IBMJSSE2 Provider performs hostname
verification and rejects requests where the host to connect to and the server
name from the certificate do not match. A HostnameVerification implementation
called "com.ibm.jsse2.HostnameVerifierIgnore" is provided. "com.ibm.jsse2.HostnameVerifierIgnore"
always accepts the connection even when a mismatch occurs.
- Tracing no longer requires the debug version of the IBMJSSE2 Provider.
- IBMJSSE2 implementation supports the new TrustManager which implements
rules for certificate chain path validation.
- The class com.ibm.jsse.SSLContext which in IBMJSSE is used to access secure
tokens has been removed.
The IBMJSSE2 Provider differs from the Sun JSSE in the following ways:
- The IBM JSSE provider is called "com.ibm.jsse2.IBMJSSEProvider2".
- The IBM KeyManagerFactory is called "IbmX509".
- The IBM TrustManagerFactory is called "IbmX509" or "IbmPKIX".
- The IBM HTTPS protocol handler is called "com.ibm.net.ssl.www.protocol.Handler".
- IBMJSSE2 does not support the com.sun.net.ssl framework; use the javax.net.ssl
framework instead.
- You can use PKIK revocation checking by setting the system property com.ibm.jsse2.checkRevocation
to "true".
- The IBM implementation supports the following protocols for
the engine class SSLContext, for the api setEnabledProtocols in the SSLSocket,
and for SSLServerSocket classes:
- SSL
- SSLv3
- TLS
- TLSv1
- SSL_TLS
The IBM implementation does not support the "SSLv2Hello"
protocol. The IBM implementation supports the SSL v2 protocol. You can
use the IBM SSLContext getInstance() factory method to control which protocols
are enabled for an SSL connection. Using SSLContext's getInstance() or the
setEnabledProtocols() methods provides the same result. With Sun's JSSE,
the protocol is controlled through setEnabledProtocols().
- IBM and Sun support different cipher suites.
- The IBM JSSE framework allows the addition of other JSSE providers.
Sun's framework currently does not.
- IBMJSSE2 uses IBM JCE Providers only for its cryptography.
- The IBM JSSE TrustManager does not allow anonymous ciphers.
To handshake with an anonymous cipher, a custom TrustManager that allows anonymous
ciphers must be provided.
- When a null KeyManager is passed to SSLContext, the IBM JSSE KeyManagerFactory
implemention will check system properties, then jssecacerts, if it exists,
and finally uses the cacerts file to find the key material. Sun's JSSE creates
an empty KeyManager.
- The IBM JSSE X509TrustManager and X509KeyManager throws an
exception if the TrustStore or KeyStore specified by the system properties
does not exist, if the password is incorrect, or if the keystore type is inappropriate
for the actual keystore. Sun's X509TrustManager creates a default TrustManager
or KeyManager with an empty keystore.
- The IBM JSSE implementation verifies the entire server or client
certificate chain, including trusted certificates. For example, if a trusted
certificate has expired, the handshake fails, even though the expired certificate
is trusted. Sun's JSSE verifies the certificate chain up to the trusted certificate.
Verification stops when it reaches a trusted certificate and the trusted
certificate and beyond are not verified.
- The IBM JSSE implementation returns the same set of supported
ciphers for the methods getDefaultCiphersSuites and getSupportedCipherSuites.
Sun's JSSE getDefaultCipherSuites returns the list of cipher suites that
provide confidentiality protection and server authentication (that is, no
anonymous cipher suites). Sun's getEnabledCipherSuites returns the entire
list of cipher suites that Sun supports.
- For Sun's implementation, DSA server certificates can use
only *_DH*_* cipher suites. For the IBM implementation, if the server has a DSA
certificate only and only RSA* ciphers are enabled, the connection succeeds
with an RSA cipher. DSA will be used for authentication and ephemeral RSA
will be used for the key exchange.
- The IBM JSSE implementation does not support the new TrustManager
which implements rules for certificate chain path validation that Sun added
to v1.4.2. The new IBMJSSE Provider2 contains this support.
- The IBM SDK supports the NTLM authentication scheme.
To switch off NTLM authentication, set the system property com.ibm.NONTLM.
The IBMJSSE2 Provider is new for v1.4.2.
The following change takes effect from v1.4.2 Service Refresh
8:
- When IBMJSSE2 is used as a server, if the SSLv3 protocol is to be used
for the handshake, it will no longer agree to use any of the AES cipher suites.
Previously, the selection of the cipher suite was independent of the protocol
selected so you could do an old-style SSLv3 handshake with a more modern AES
cipher suite. The TLS protocol is not affected by this change. This change
was required to support Microsoft Vista clients.
For detailed information, including API documentation and samples, see
the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The IBM Java JCE (Java Cryptographic Extension) FIPS Provider
(IBMJCEFIPS) for multi-platforms is a scalable, multi-purpose cryptographic
module that supports FIPS-approved cryptographic operations through Java APIs.
The IBMJCEFIPS includes the following Federal Information Processing Standards
(FIPS) 140-2 [Level 1] compliant components:
- IBMJCEFIPS for Solaris,
- IBMJCEFIPS for HP
- IBMJCEFIPS for Windows
- IBMJCEFIPS for z/OS(R)
- IBMJCEFIPS for AS/400(R)
- IBMJCEFIPS for Linux(R) (Red Hat and SUSE)
To meet the requirements specified in the FIPS publication 140-2, the
encryption algorithms used by the IBMJCEFIPS Provider are isolated into the
IBMJCEFIPS Provider cryptographic module, which you can access using the product
code from the Java JCE framework APIs. Because the IBMJCEFIPS Provider
uses the cryptographic module in an approved manner, the product complies
with the FIPS 140-2 requirements.
Type |
Algorithm |
Specification |
Symmetric Cipher |
AES (ECB, CBC, OFB, CFB and PCBC) |
FIPS 197 |
Symmetric Cipher |
DES (ECB, CBC, OFB, CFB and PCBC) - for legacy systems only
Triple DES (ECB, CBC, OFB, CFB and PCBC)
|
FIPS 46-3 |
Message Digest |
SHA1
HMAC-SHA1
|
FIPS 180-1
FIPS 198
|
Asymmetric Cipher |
RSA |
PKCS#1 |
Key Agreement |
Diffie-Hellman |
PKCS #3 (Allowed in Approved mode) |
Random Number Generator |
X 9.31 PRNG |
ANSI X 9.31 1998 |
Random Number Generator |
FIPS 186-2 Appendix 3.1 |
FIPS 186-2 |
Digital Signature |
DSA (512 - 1024) |
FIPS 186-2 |
Digital Signature |
RSA (512 - 2048) |
FIPS 186-2 |
In addition, the IBMJCEFIPS supports the following unapproved algorithms:
Type |
Algorithm |
Specification |
Random Number Generation |
Universal Software Based Random Number Generator |
Available upon request from IBM. Patented by IBM,
EC Pat. No. EP1081591A2, U.S. pat. Pend. |
Note:
The com.ibm.crypto.fips.provider.IBMJCEFIPS class does not
include a keystore (such as JKS or JCEKS) because of FIPS requirements and
algorithms. Therefore, if you are using com.ibm.crypto.fips.provider.IBMJCEFIPS
and require JKS, you must specify the com.ibm.crypto.provider.IBMJCE in the
provider list.
For more detailed information on the FIPS certified providers (IBMJCEFIPS
and IBMJSSEFIPS) see the IBM Java JCE FIPS 140-2 Cryptographic Module
Security Policy, and the IBM Java JSSE FIPS 140-2 Cryptographic Module
Security Policy. For usage information and details of the API, see the IBM Java JCE FIPS (IBMJCEFIPS) Cryptographic
Module API document. All these documents are available at http://www.ibm.com/developerworks/java/jdk/security/index.html.
Sun does not provide IBMJCEFIPS.
The IBMJCEFIPS Provider is new for v1.4.2.
For detailed information, including API documentation and Security Policy,
see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
The IBM Java JSSE (Java Secure Sockets Extension) FIPS 140-2
Cryptographic Module (IBMJSSEFIPS) for Multi-platforms is a scalable, multi-purpose
Secure Sockets provider that supports FIPS-approved TLS cipher suites through
the Java APIs. The IBMJSSEFIPS includes the following Federal Information
Processing Standards (FIPS) 140-2 [1] compliant components:
- IBMJSSEFIPS for Solaris,
- IBMJSSEFIPS for HP,
- IBMJSSEFIPS for Windows
- IBMJSSEFIPS for z/OS
- IBMJSSEFIPS for AS/400
- IBMJSSEFIPS for Linux (Red Hat and SUSE)
To meet the requirements specified in the FIPS publication 140-2, the
encryption algorithms used by the IBMJSSEFIPS Provider are isolated into the
IBMJSSEFIPS Provider cryptographic module, which you can access using the
product code from the Java JSSE framework APIs. Because the
IBMJSSEFIPS Provider uses the cryptographic module in an approved manner,
the product complies with the FIPS 140-2 requirements.
The IBMJSSEFIPS module supports the TLS protocol and the following cipher
suites:
- SSL_RSA_WITH_DES_CBC_SHA (hex number 0009)
- SSL_RSA_FIPS_WITH_DES_CBC_SHA (hex number FEFE)
- SSL_RSA_WITH_3DES_EDE_CBC_SHA (hex number 000A)
- SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (hex number FEFF)
- SSL_RSA_WITH_AES_128_CBC_SHA (hex number 002F)
- SSL_RSA_WITH_AES_256_CBC_SHA (hex number 0035)
- SSL_DHE_RSA_WITH_AES_128_CBC_SHA (hex number 0033)
- SSL_DHE_RSA_WITH_AES_256_CBC_SHA (hex number 0039)
- SSL_DHE_RSA_WITH_DES_CBC_SHA (hex number 0015)
- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (hex number 0016)
- SSL_DHE_DSS_WITH_AES_128_CBC_SHA (hex number 0032)
- SSL_DHE_DSS_WITH_AES_256_CBC_SHA (hex number 0038)
- SSL_DHE_DSS_WITH_DES_CBC_SHA (hex number 0012)
- SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA (hex number 0062)
- SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0008)
- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (hex number 0014)
- SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (hex number 0063)
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (hex number 0011)
- SSL_DH_anon_WITH_AES_128_CBC_SHA (hex number 0034)
- SSL_DH_anon_WITH_AES_256_CBC_SHA (hex number 003A)
- SSL_DH_anon_WITH_DES_CBC_SHA (hex number 001A)
- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA (hex number 001B)
- SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA (hex number 0019)
The IBMJSSEFIPS module has no direct user interfaces. This module is a
JSSE provider and the interface to it is from the JSSE framework APIs only.
Your Java code should use only those IBM JSSE interfaces that are documented in
the JSSE API User's Guide and associated IBMJSSEProvider Class Documentation. For more information, see the IBM Java JSSE FIPS 140-2 Cryptographic Module
Security Policy. You can find these guides at http://www.ibm.com/developerworks/java/jdk/security/index.html
Sun does not provide IBMJSSEFIPS.
The IBMJSSEFIPS Provider is new for v1.4.2.
For detailed information, including API documentation and Security Policy,
see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.
This information was developed for products and services offered in the
U.S.A. IBM may not offer the products, services, or features discussed in this
document in other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM product,
program, or service is not intended to state or imply that only that IBM product, program,
or service may be used. Any functionally equivalent product, program, or service
that does not infringe any IBM intellectual property right may be used instead. However,
it is the user's responsibility to evaluate and verify the operation of any
non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject
matter in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing,
to:
- IBM Director of Licensing
IBM Corporation
North
Castle Drive, Armonk
NY 10504-1758 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact
the IBM Intellectual Property Department in your country or send inquiries,
in writing, to:
- IBM World Trade Asia Corporation Licensing
2-31
Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS
IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement
may not apply to you.
This information could include technical inaccuracies or typographical
errors. Changes are periodically made to the information herein; these changes
will be incorporated in new editions of the information. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this information
at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those
Web sites. The materials at those Web sites are not part of the materials
for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way
it believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the
purpose of enabling (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact:
- JIMMAIL@uk.ibm.com
[Hursley Java Technology
Center (JTC) contact]
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International
Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary significantly.
Some measurements may have been made on development-level systems and there
is no guarantee that these measurements will be the same on generally available
systems. Furthermore, some measurement may have been estimated through extrapolation.
Actual results may vary. Users of this document should verify the applicable
data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers
of those products, their published announcements or other publicly available
sources. IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
IBM, developerWorks, iSeries, pSeries,
AS/400, and PowerPC are trademarks or registered trademarks of International
Business Machines Corporation in the United States, or other countries, or
both.
Java and all Java-based trademarks are trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks
of Microsoft Corporation in the United States, other countries, or both
Other company, product, or service names may be trademarks or service marks
of others.