# IBM SDK for Linux platforms, Java Technology Edition

# Security User Guide

Version 5 Release 0
Note

This documentation applies to IBM SDK for Linux, v5.0 releases before SR 13. For new or changed information about IBM SDK for Linux, v5.0 SR 13 and newer, see IBM SDK for Linux, v5.0: Current news.

Before using this information and the product it supports, read the information in Notices.

Copyright information

This edition of the user guide applies to the security components included with the IBM SDK for Java.

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.1 Provider
- IBM Java Cryptography Extension (JCE) Provider
- IBM Java Generic Security Service (JGSS) v1.5 Provider
- IBM Java Secure Socket Extension (JSSE) IBM JSSE2 Provider
- IBM PKCS11 Implementation Provider
- IBM Java JCE FIPS Provider
- IBM Simple Authentication and Security Layer (SASL) Provider v1.5
- Key Certificate Management utilities

and to all subsequent releases and modifications until otherwise indicated in new editions.

© Copyright 1997, 2011, Oracle and/or its affiliates. All rights reserved.

Copyright International Business Machines Corporation 2003, 2011.
US Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

# Contents

Preface
General information about IBM security providers
iKeyman tool
Java Authentication and Authorization Service (JAAS) V2.0
History of changes
Java Certification Path (CertPath)
History of changes
Java Cryptography Extension (JCE)
History of changes
Java Generic Security Service (JGSS)
History of changes
IBMJSSE2 Provider
Differences between the IBMJSSE Provider and the IBMJSSE2 Provider
Differences between the IBMJSSE2 Provider and the Oracle version of JSSE
History of changes
IBMJSSE2 support for RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension
IBMPKCS11Impl Provider
History of changes
IBMJCEFIPS Provider
IBM SASL Provider
IBM Key Certificate Management
Keytool
Notices
Trademarks

# Preface

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. IBM does not provide support for any of the IBM Java security components when used with a non-IBM JVM or with non-IBM security providers when used with the IBM JVM.

The IBM SDK also provides a FIPS 140-2 certified cryptographic module, IBMJCEFIPS, implemented as a JCE provider. Applications can comply with the FIPS 140-2 requirements by using the IBMJCEFIPS module.

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 implementation of the SSL and TLS protocols. The JSSE pre-registered default provider is IBMJSSE2.

IBM Java Simple Authentication and Security Layer, or SASL, is an Internet standard (RFC 2222) that specifies a protocol for authentication and optional establishment of a security layer between client and server applications.

The Java security configuration file does not refer to the Oracle provider. The IBM JCE provider has replaced the Oracle provider. The JCE supplies all the signature handling message digest algorithms that were previously supplied by the Oracle 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 Oracle 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 caught 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, there is a 'What's new' section for each component. This information is provided to help you with migration.

# General information about IBM security providers

Overview of the IBM security providers.

The IBM SDK v5.0 has been tested with the following default security providers:

- security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
- security.provider.2=com.ibm.crypto.provider.IBMJCE
- security.provider.3=com.ibm.security.jgss.IBMJGSSProvider
- security.provider.4=com.ibm.security.cert.IBMCertPath
- security.provider.5=com.ibm.security.sasl.IBMSASL

IBM do not provide a separate ECC provider.

You can also add other IBM security providers, such as the IBMJCEFIPS provider (com.ibm.crypto.fips.provider.IBMJCEFIPS), using one of these methods:

1. To add a new provider statically, edit a Java security properties file. For example, the`java.security` file.
2. To add a new provider from within your application, use the methods of the java.security.Security class. For example:

       java.security.Security.addProvider()

Code written for the IBMJSSE Provider might not compile or run in the same way for IBMJSSE2. For details, see IBMJSSE2 Provider.

# iKeyman tool

The iKeyman utility is a tool for key databases containing digital certificates and keys.

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

To load a Java cryptographic token on SLES10 using iKeyman, you must rename the cryptography library from `/usr/lib/opencryptoki/libopencryptoki.so.0.0.0:0` to `/usr/lib/opencryptoki/libopencryptoki.so`. If `/usr/lib/opencryptoki/libopencryptoki.so` is already linked, you must delete it before the renaming.

## History of changes

Version 1.4.1
  Added an iKeyman wrapper that starts the correct tool class.

## Documentation

For more information, including information about the iKeyman GUI, see the iKeyman User Guide at: http://www.ibm.com/developerworks/java/jdk/security/index.html.

# Java Authentication and Authorization Service (JAAS) V2.0

The Oracle Corporation Java 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 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 security architecture requires the following:

- Additional support for authentication (determining who is 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 Oracle Web site: http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html.

## Differences between IBM and Oracle versions of JAAS

IBM implementations are contained in the com.ibm.* package instead of the com.sun.* package.

## Further reading

For detailed information, including API documentation and samples, see the developerWorks® Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html. This site contains the LoginModule Developer's Guide and sample code in "HelloWorld.tar".

## History of changes

A history of the changes to the Java Authentication and Authorization Service (JAAS) since it was added to the SDK.

### Original release

New to the IBM 32-bit SDK for Linux on Intel architecture

The original release of JAAS for Linux and the Java Platform included the following login module and principal classes:

- com.ibm.security.auth.module.LinuxLoginModule
- com.ibm.security.auth.LinuxPrincipal
- com.ibm.security.auth.LinuxNumericGroupPrincipal
- com.ibm.security.auth.LinuxNumericUserPrincipal

These original platform-dependent principal classes will be replaced by a set of platform-independent principal classes in future releases of JAAS for Linux. To ease migration, this version of JAAS contains the original set as well as the new set of principal classes. Also included is a new login module called com.ibm.security.auth.module.LinuxLoginModule2000, which has the same function as LinuxLoginModule but references the new set of principals. Additional principal classes have been included to facilitate the writing of new login modules.

You are encouraged to use the new set of principals when developing applications that use JAAS. Previously developed applications will be compatible with this version as well as future versions of JAAS released for the SDK v1.4.0.

If migrating applications to the new set of principals is desired, then most changes encountered will be in JAAS policy and configuration files rather than in the applications. Refer to the following table for guidance.

Table 1. New class names
Original class | Replaced by
--- | ---
LinuxPrincipal | UsernamePrincipal
LinuxNumericGroupPrincipal | GroupIDPrincipal PrimaryGroupIDPrincipal
LinuxNumericUserPrincipal | UserIDPrincipal
n/a | DomainPrincipal
n/a | DomainIDPrincipal
n/a | ServerPrincipal
n/a | WkstationPrincipal
LinuxLoginModule | LinuxLoginModule2000

Principal classes are found in the com.ibm.security.auth package while the login module is found in the com.ibm.security.auth.module package. Check the JAAS API documentation (Javadoc information) for more information on the new principal classes.

For example, this JAAS policy grant block:

    grant Principal com.ibm.security.auth.LinuxPrincipal "bob",
          Principal com.ibm.security.auth.LinuxNumericUserPrincipal
               "727",
          Principal com.ibm.security.auth.LinuxNumericGroupPrincipal
               "12" {
       permission java.util.PropertyPermission "java.home", "read";
    };

is replaced by:

    grant Principal com.ibm.security.auth.UsernamePrincipal "bob",
          Principal com.ibm.security.auth.UserIDPrincipal "727",
          Principal com.ibm.security.auth.GroupIDPrincipal "12" {
       permission java.util.PropertyPermission "java.home", "read";
    };

# Java Certification Path (CertPath)

The Java Certification Path API provides interfaces and abstract classes for creating, building, and validating certification paths (also known as "certificate chains").

## Differences between IBM and Oracle versions of CertPath

The IBM CertPath classes differ from the Oracle version in the following ways:

- The IBM CertPath provider is in the package com.ibm.security.cert.
- The IBM CertPath provider is called "IBMCertPath". Oracle does not have a separate provider for CertPath.
- To enable CRL Distribution Points extension checking, use the system property `com.ibm.security.enableCRLDP`. The system property used by the Oracle version is `com.sun.security.enableCRLDP`.
- When checking the CRL Distribution Points extension of the certificate, the Oracle CertPath provider 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.

## Documentation

For detailed information, including API documentation and samples, see the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.

## History of changes

A history of the changes to CertPath since it was added to the SDK.

### Changes for Version 5.0

- Added support for checking a certificate's revocation status based on On-Line Certificate Status Protocol (OCSP).
- Added a new constructor and a public API in the TrustAnchor class:

      public TrustAnchor(X500Principal caPrincipal, PublicKey pubKey, byte[]
      																												nameConstraints);
      public final X500Principal getCA();

- Added new public APIs in X509CertSelector:

      public X500Principal getIssuer();
      public void setIssuer(X500Principal issuer);
      public X500Principal getSubject();
      public void setSubject(X500Principal subject);

- Added new public APIs in X509CRLSelector:

      public void setIssuers(Collection issuers);
      public void addIssuer(X500Principal issuer);
      public Collection getIssuers();

- Changed the PolicyQualifier class to non-final. The public APIs have changed to be final.

### Changes for Version 1.4.2

- Improved the performance of the IBM CertPath provider.
- Added limited support for the CRL Distribution Points extension.
- Added caching to cache lookups in the IBM LDAP CertStore.

### Changes for Version 1.4.1, Service Refresh 1

- 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.

### Changes for Version 1.4.0

- Certificates from CertificatePair entry can be retrieved from LDAP type certstore.
- Changed the framework package name from javax.security.cert to java.security.cert. The old framework package is still supported.

# Java Cryptography Extension (JCE)

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 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. The policy files are replaced with restricted policy files when you upgrade your SDK. Before upgrading your SDK, make a backup of your policy files. After upgrading your SDK, install your backup policy files if you need an unrestricted policy.

The v1.4.2 unrestricted (and restricted) jurisdiction policy files are suitable for use with v5.0 and later. The v1.4.1 files are not suitable.

## Differences between IBM and Oracle versions of JCE

The com.sun.* packages are reimplemented by IBM and renamed com.ibm.* packages.

The IBM version of JCE differs from the Oracle 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 Oracle providers sun.security.provider.Sun, com.sun.rsajca.Provider, and com.sun.crypto.provider.SunJCE.
- IBM provides more algorithms than Oracle does:
  Cipher algorithms
    AES

    Blowfish

    DES

    El Gamal

    Mars

    ARCFOUR

    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

    RSA encryption/decryption with OAEP Padding

    Seal

    Triple DES

  Signature algorithms
    SHA1 with RSA

    SHA2 with RSA

    SHA3 with RSA

    SHA5 with RSA

    MD5 with RSA

    MD2 with RSA signature

    SHA1 with DSA signature

  Message digest algorithms
    SHA1

    SHA2

    SHA3

    SHA5

    MD5

    MD2

  Message authentication code (MAC)
    Hmac/SHA1

    Hmac/MD5

    Hmac/SHA2

    Hmac/SHA3

    Hmac/SHA5

  Key agreement algorithm
    DiffieHellman
  Random number generation algorithms
    IBMSecureRandom

    IBM SHA1PRNG

  Key Store
    JCEKS

    JKS

    PKCS12KS

## Documentation

For detailed information, including API documentation and samples, see the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.

## History of changes

A history of the changes to the Java Cryptography Extension (JCE) since it was added to the SDK.

### Changes for Version 5.0, Service Refresh 4

- Added the EL Gamal Cipher and supporting classes.

### Changes for Version 5.0

- Added RSA with OAEP Padding.
- Added the SHA2withRSA, SHA3withRSA and SHA5withRSA signature algorithms.
- Added the HmacSHA2, HmacSHA3, HmacSH5 MAC algorithms.
- Added the ARCFOUR encryption algorithm.

### Changes for Version 1.4.2

- Added the SHA2, SHA3 and SHA5 hashing algorithms.
- Added the SHA1PRNG algorithm for generating pseudo random numbers.

### Changes for Version 1.4.0

- Added the AES cipher algorithm.
- Changed to strong cryptography by 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.

# Java Generic Security Service (JGSS)

Java Generic Security Service (JGSS) API provides secure exchange of messages between communicating applications.

JGSS is an API framework that uses 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, which is based on CodeSource with access controls based on authenticated principal identities.

## Differences between the IBM and Oracle versions of JGSS

The IBM version of JGSS differs from the Oracle 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 the equivalent tools provided in the Oracle version of JGSS.

## Documentation

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.

## History of changes

A history of the changes to the Java Generic Security Service (JGSS) since it was added to the SDK.

### Changes for Version 5.0, Service Refresh 1

Added AES as a supported algorithm type
  These additional algorthims can be set in the `krb5.conf` file under [libdefault] as follows:
  default_tkt_enctypes = aes128-cts-hmac-sha1-96
  default_tkt_enctypes = aes256-cts-hmac-sha1-96
  default_tgs_enctypes = aes128-cts-hmac-sha1-96
  default_tgs_enctypes = aes256-cts-hmac-sha1-96
  default_checksum = hmac-sha1-96-aes128
  default_checksum = hmac-sha1-96-aes256

### Changes for Version 5.0

TCP or UDP Preference Configuration
  Added JSE support for the `udp_preference_limit` property in the Kerberos configuration file `krb5.ini`. When sending a message to the KDC, the JSE Kerberos library uses TCP if the size of the message is above `udp_preference_list`. If the message is smaller than `udp_preference_list`, UDP is tried up to three times. If the KDC indicates that the request is too big, the JSE Kerberos library uses TCP.
IPv6 support in Kerberos
  Added JSE support for IPv6 addresses in Kerberos tickets. Before v5.0, only IPv4 addresses were supported in tickets.
TGT Renewals
  Added support for Ticket Granting Ticket (TGT) renewal to the Java Authentication and Authorization Service (JAAS) Kerberos login module, Krb5LoginModule. This support allows long-running services to renew their TGTs automatically without user interaction or requiring the services to restart. With this feature, if Krb5LoginModule obtains an expired ticket from the ticket cache, the TGT is automatically renewed and is added to the Subject of the caller who requested the ticket. If the ticket cannot be renewed for any reason, Krb5LoginModule uses the configured callback handler to retrieve a username and password to acquire a new TGT.

  To use this feature, configure Krb5LoginModule to use the ticket cache and set the newly introduced `renewTGT` option to true. Here is an example of a JAAS login configuration file that requests TGT renewal:

      server {
      	com.ibm.security.auth.module.Krb5LoginModule required
      	principal=principal@your_realm
      		useDefaultCcache=TRUE
      		 renewTGT=true;
      };

  Note that if `renewTGT` is set to `true`, `useDefaultCcache` must also be set to true; otherwise, it results in a configuration error.

### Changes for Version 1.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 are refreshed before the login method of the Krb5LoginModule is called.
Added support for Slave Kerberos Key Distribution Center
  Kerberos uses slave KDCs so that, if the master KDC is unavailable, the slave KDCs respond to your requests. In previous releases, Kerberos tried the master KDC only and gave up if there was no response in the default KDC timeout period.
Added support for 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 Private Credentials of the Subject
  The Kerberos service ticket is stored in the private credentials of the Subject. This gives you access to the service ticket so that you can use the ticket 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 must be valid for it to be reusable.

### Changes for Version 1.4.1

- Added wrappers for the `klist`, `kinit`, and `ktab` Java tools. These wrappers call the relevant tool classes so that you do not have to remember the full package name.

# IBMJSSE2 Provider

The Java Secure Socket Extension (JSSE) is a Java package that enables secure internet communications. The package implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols. It 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 FIPS provider included with the SDK is undergoing certification with the US Government. The certification progress is available on the CSRC Web site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf.

## Documentation

For detailed information, including API documentation and samples, see http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Differences between the IBMJSSE Provider and the IBMJSSE2 Provider

The IBMJSSE2 Provider, which was introduced in the v1.4.2 SDK, has replaced the IBMJSSE Provider. Although they are nearly equivalent, there are differences between the two providers.

The now-discontinued IBMJSSE Provider and the IBMJSSE2 Provider differ in the following ways:

- The IBMJSSE2 Provider is called com.ibm.jsse2.IBMJSSEProvider2.
- The HTTPS protocol handler for the IBMJSSE2 Provider is called com.ibm.net.ssl.www2.protocol.Handler. The com.ibm.net.ssl.internal.www.protocol.Handler and the com.ibm.net.ssl.www.protocol.Handler protocol handlers have been removed.
- 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. However, the server side of a JSSE2 connection does accept the SSLv2Hello protocol.
- The AES_256 ciphers require the installation of the JCE Unlimited Strength Jurisdiction Policy. The old IBMJSSE Provider did not use JCE for its cryptographic support and therefore did not require these files.
- The IBMJSSE2 Provider requires a JCE Provider for its cryptography.
- The IBMJSSE2 Provider does not build the server's private key certificate chain from the trusted keystore. The trusted certificates must be added to the server's private key to complete the chain. This is an incompatible change.
- 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 a separate debug jar.
- The class com.ibm.jsse.SSLContext, which in IBMJSSE is used to access secure tokens, has been removed. Use the hardware crypto support in IBMJSSE2 instead. See the documentation on the developerWorks Web site http://www.ibm.com/developerworks/java/jdk/security/index.html for details.
- The IBMJSSEFIPS Provider has been removed. JSSE FIPS support is supported in the IBMJSSE2 Provider and no separate jar is required. See the documentation on the developerWorks Web site http://www.ibm.com/developerworks/java/jdk/security/index.html for instructions how to set up JSSE to run in FIPS mode.

## Differences between the IBMJSSE2 Provider and the Oracle version of JSSE

Although they are nearly equivalent, there are differences between the IBMJSSE2 Provider and the Oracle JSSE Provider.

The IBMJSSE2 Provider differs from the Oracle 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.www2.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 the SSLContext `getInstance()` or the `setEnabledProtocols()` methods provides the same result. With the Oracle version of JSSE, the protocol is controlled through `setEnabledProtocols()`.
- IBM and Oracle support different cipher suites.
- 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 implementation first checks the system properties. Next, if it exists, jssecacerts is checked. Finally, the `cacerts` file is used to find the key material. The Oracle version of JSSE creates an empty KeyManager.
- The IBM JSSE X509TrustManager and X509KeyManager throws an exception if any one of three conditions are true:
  - The TrustStore or KeyStore specified by the system properties does not exist.
  - The password is incorrect.
  - The keystore type is inappropriate for the actual keystore.
  The Oracle version of 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. The Oracle version of 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()`. The Oracle version of `getDefaultCipherSuites()` returns the list of cipher suites that provide confidentiality protection and server authentication (that is, no anonymous cipher suites). Oracle's `getEnabledCipherSuites()` returns the entire list of cipher suites that Oracle supports.
- For the Oracle 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.
- To use a hardware keystore or truststore on an IBM hardware crypto provider with system properties, set the `javax.net.ssl.keyStoreType` and `javax.net.ssl.trustStoreType` system properties to "PKCS11IMPLKS". For the Oracle implementation, the system property is set to "PKCS11".
- The IBM JSSE Provider can be enabled to run in FIPS mode. The Oracle JSSE cannot.

## History of changes

A history of the changes to the IBMJSSE2 Provider since it was added to the SDK.

### Change for Version 5.0, Service Refresh 12

- IBM JSSE2 allows SSL V3 or TLS V1 session renegotiation with peers that have implemented RFC 5746: Transport Layer Security (TLS) - Renegotiation Indication Extension. For more information, see: IBMJSSE2 support for RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension

### Changes for Version 5.0, Service Refresh 5

- 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.

### Changes for Version 5.0

- Removed the IBMJSSE Provider. Use the IBMJSSE2 Provider instead.
- The IBMJSSE2 implementation supports only IBM hardware cryptographic providers. Applications that ran in v1.4.2 using the IBMPKCS11Impl provider will now be required to use a configuration file in order to run successfully.
- SSLEngine (non-blocking I/O) allows SSL/TLS applications to choose their own I/O and compute models.
- Enhanced TrustManager support for HTTP/HTTPS.
- New and updated Methods and Classes.
- Kerberos cipher suites are available, if supported by the operating system.

### Changes for Version 1.4.2.

The IBMJSSE2 Provider is new for Version 1.4.2.

## IBMJSSE2 support for RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension

IBM JSSE2 allows SSL V3 or TLS V1 session renegotiation with peers that have implemented RFC 5746.

The IETF has published RFC 5746 Transport Layer Security (TLS) - Renegotiation Indication Extension. RFC 5746 defines a mechanism to implement TLS/SSL handshake renegotiation securely. Use of RFC 5746 replaces the industry wide interim solution of disabling all renegotiation implemented after the weakness was discovered.

After applying this APAR, IBM JSSE2 allows SSL V3 or TLS V1 session renegotiation with peers that have implemented RFC 5746. Session renegotiation with peers that do not support RFC 5746 reverts to the interim disablement solution. By default, unsecured renegotiation is not allowed. Use the system property `com.ibm.jsse2.renegotiate` to control how unsecured negotiations are handled by IBM JSSE2.

Read RFC 5746 for additional details if interested in the underlying TLS protocol changes to correct the weakness.

The following system properties are available to control how restrictive IBM JSSE2 is in the enforcement of RFC 5746:

com.ibm.jsse2.extended.renegotiation.indicator=[BOTH | CLIENT | OPTIONAL | SERVER]
  Use this property to force all negotiations to require RFC 5746, not just renegotiations. This negotiation would only be practical after all the required communication partners have implemented RFC 5746. The default setting is `OPTIONAL`.
  com.ibm.jsse2.extended.renegotiation.indicator=BOTH
    Causes the IBM JSSE2 Server or IBM JSSE2 client to connect only if the peer indicated support for RFC 5746 renegotiation.
    Note: Setting the property to `BOTH` causes interoperability problems with clients or servers that have not been updated to support RFC 5746.
  com.ibm.jsse2.extended.renegotiation.indicator=CLIENT
    Causes the IBM JSSE2 Client to connect only if the server indicated support for RFC 5746 Renegotiation.
    Note: Setting the property to `CLIENT` causes interoperability problems with servers that have not been updated to support RFC 5746.
  com.ibm.jsse2.extended.renegotiation.indicator=OPTIONAL
    This setting is the default. Using this option means that the IBM JSSE2 Server or IBM JSSE2 Client do not require the renegotiation indicator during the initial handshake.
  com.ibm.jsse2.extended.renegotiation.indicator=SERVER
    Causes the IBM JSSE2 Server to connect only if the client indicated support for RFC 5746 Renegotiation.
    Note: Setting the property to `SERVER` causes interoperability problems with clients that have not been updated to support RFC 5746.
com.ibm.jsse2.renegotiate = [ABBREVIATED | ALL | DISABLED | NONE]
  Use this property to change the renegotiation ability of IBM JSSE2. The default value is `NONE`.
  com.ibm.jsse2.renegotiate=ABBREVIATED
    This setting overrides and allows unsecured abbreviated handshake during renegotiation when session continuity is proven. RFC 5746 renegotiations are allowed.
  com.ibm.jsse2.renegotiate=ALL
    This setting overrides and allows unsecured full handshake, and unsecured abbreviated handshake, during renegotiation. RFC 5746 renegotiations are allowed.
  com.ibm.jsse2.renegotiate=DISABLED
    This setting overrides and disables all unsecure and RFC 5746 renegotiations.
  com.ibm.jsse2.renegotiate=NONE
    This setting is the default. No unsecured handshake renegotiation is allowed. Only RFC 5746 renegotiations are allowed.
com.ibm.jsse2.renegotiation.peer.cert.check=[OFF | ON]
  Use this property to change the renegotiation ability of IBM JSSE2 to require the peer support specified in RFC 5746. This requirement is only practical after all the required communication partners have implemented RFC 5746. The default value is `OFF`.
  com.ibm.jsse2.renegotiation.peer.cert.check=OFF
    This setting is the default. It stops the IBM JSSE2 Client or IBM JSSE2 Server performing an identify check against the certificate from the peer. The result is to allow the peer certificate to change during renegotiation.
  com.ibm.jsse2.renegotiation.peer.cert.check=ON
    This setting causes the IBM JSSE2 Client or IBM JSSE2 Server to perform a comparison against the certificate from the peer. The reason is to ensure that the certificate does not change during renegotiation. The comparison is applicable to both secure and non-secure renegotiations.

# IBMPKCS11Impl Provider

The IBMPKCS11Impl Provider uses the Java Cryptography Extension (JCE) and Java Cryptography Architecture (JCA) frameworks to add the ability to use hardware cryptography through the Public Key Cryptographic Standards #11 (PKCS #11) standard.

This provider takes advantage of hardware cryptography in the existing JCE architecture. It gives Java programmers the significant security and performance advantages of hardware cryptography with minimal changes to existing Java applications. Because the complexities of hardware cryptography are handled in the normal JCE, advanced security and performance using hardware cryptographic devices is available readily.

PKCS#11 is a standard that provides a common application interface to cryptographic services on various platforms through several hardware cryptographic devices. See the IBMPKCS11Impl provider user guide for a list of supported devices.

Remember: Use the correct PKCS11 configurations files for Version 5 of the SDK. You can download sample configuration files from http://www.ibm.com/developerworks/java/jdk/security/50/.

## Differences between IBM and Oracle versions of IBMPKCS11Impl

- The Oracle keystore is named PKCS11 and the IBM keystore is called IBMPKCS11KS.
- The Oracle keystore requires that all trusted certificates have the attribute `CKA_TRUSTED` set to true. The IBM keystore assumes that any certificates on the device are trusted. The IBM keystore can work with data that was saved using the Oracle keystore. However, the Oracle keystore might not be able to work with data saved using the IBM keystore.

## Documentation

For detailed information, including API documentation, see the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.

## History of changes

A history of the changes to the IBMPKCS11Impl Provider since it was added to the SDK.

### Changes for Version 5.0

Updated IBMPKCS11Impl to allow more algorithms and to allow the Oracle 5.0 methods of initialization of the provider. The new algorithms are:

- AES
- Diffie-Hellman
- RC4, also known as ArcFour
- Blowfish
- SHA-256
- SHA-384
- SHA-512
- SHA256withRSA
- SHA384withRSA
- SHA512withRSA
- HmacMD5
- HmacSHA1
- HmacSHA256
- HmacSHA384
- HmacSHA512

Added the ability to pass in a configuration file to the provider. This configuration file can contain a significant amount of information about the device; for example, what it should or should not do. After the provider is created, the application can log in to the card in different ways. Some devices allow you to perform some cryptographic functions without logging into the device. The v1.4.2 ways to initialize the device still work. However, you can no longer have more than one of these providers at a time. Instead, with this release, you can initialize more than one IBMPKCS11Impl provider using the 5.0 configuration file and login methods.

Deprecated the classes DESPKCS11KeyParameterSpec and DESedePKCS11KeyParameterSpec. Use the GeneralPKCS11KeyParameterSpec class for all symmetric key types (for instance, DES, DESede, AES, RC4, Blowfish).

### Changes for Version 1.4.2

The IBMPKCS11Impl Provider was new for v1.4.2.

# IBMJCEFIPS Provider

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.

IBMJCEFIPS was introduced in Version 1.4.2.

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®
- IBMJCEFIPS for AS/400®
- IBMJCEFIPS for Linux (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. You can access the module 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 | Triple DES (ECB, CBC, OFB, CFB, and PCBC) | FIPS 46-3
Message Digest | SHA1 SHA-256 SHA-384 SHA-512 HMAC-SHA1 | FIPS 180-2 FIPS 198a
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
--- | --- | ---
Asymmetric Cipher | RSA | PKCS#1
Key Agreement | Diffie-Hellman | PKCS #3 (Allowed in Approved mode)
Digital Signature | DSAforSSL | Allowed for use inside the TLS protocol
Digital Signature | RSAforSSL | Allowed for use inside the TLS protocol
Message Digest | MD5 | FIPS 180-2
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.

Important: 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 about the FIPS certified provider IBMJCEFIPS, see the IBM Java JCE 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. These documents are available at http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Differences between IBM and Oracle versions of IBMJCEFIPS

Oracle does not provide IBMJCEFIPS.

## Documentation

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.

# IBM SASL Provider

Simple Authentication and Security Layer, or SASL, is an Internet standard (RFC 2222) that specifies a protocol for authentication and optional establishment of a security layer between client and server applications. SASL defines how authentication data is to be exchanged but does not itself specify the contents of that data. It is a framework into which specific authentication mechanisms that specify the contents and semantics of the authentication data can fit.

The Java SASL API defines classes and interfaces for applications that use SASL mechanisms. It is defined to be mechanism-neutral: the application that uses the API does not need to be hardwired into using any particular SASL mechanism. The API supports both client and server applications. It allows applications to select the mechanism to use based on preferred security features, such as whether they are susceptible to passive dictionary attacks or whether they accept anonymous authentication. The Java SASL API also allows developers to use their own, custom SASL mechanisms. SASL mechanisms are installed by using the Java Cryptography Architecture (JCA).

The IBM SASL provider supports the following client and server mechanisms.

Client mechanisms
  - PLAIN (RFC 2595). This mechanism supports cleartext username/password authentication.
  - CRAM-MD5 (RFC 2195). This mechanism supports a hashed username/password authentication scheme.
  - DIGEST-MD5 (RFC 2831). This mechanism defines how HTTP Digest Authentication can be used as a SASL mechanism.
  - GSSAPI (RFC 2222). This mechanism uses the GSSAPI for obtaining authentication information. It supports Kerberos v5 authentication.
  - EXTERNAL (RFC 2222). This mechanism obtains authentication information from an external channel (such as TLS or IPsec).
Server mechanisms
  - CRAM-MD5
  - DIGEST-MD5
  - GSSAPI (Kerberos v5)

## Differences between the Oracle and IBM SASL Providers

Only the package names, for example com.ibm.security.sasl, and the provider name are different from the Oracle Implementation: com.ibm.security.sasl.IBMSASL.

## History of changes

Version 5.0
  The IBM SASL Provider is new for v5.0.

## Documentation

Detailed information, including API documentation and samples, is on the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.

# IBM Key Certificate Management

Uses of the IBM Key Certificate Management utilities.

The Key Certificate Management utilities make up a set of packages used to:

- Access keys and certificates stored in any format.
- Extract information from a KeyStore, given a Subject Key Identifier (SKI) and a set of certificate generation APIs, to create a self-signed certificate.
- Generate a CertificateRequest.
- Obtain a certificate signed by a CA.

The Key Certificate Management utilities can:

- Generate a CertificateRequest, and submit the request to a CA using the Java Public Key Infrastructure (PKI) to sign a certificate and then receive the signed certificate.
- Generate a PKCS10 request.
- Generate a Self-Signed Certificate.
- Revoke a signed certificate from a CA using the Java PKI.
- Import certificates from the input stream to the KeyStore or export certificates from the KeyStore to the output stream.
- Copy a keystore from one keystore format to another keystore format.
- Extract information from a KeyStore given a Subject Key Identifier.

The Subject Key Identifier is specified in RFC 3820, Section 4.2.1.2, http://www.faqs.org/rfcs/rfc3820.html.

## History of changes

Version 5.0, Service Refresh 1
  The Key Certificate Management utility is new for Version 5.0, Service Refresh 1.

## Documentation

The Key Certificate Management How-to Guide and Javadoc information are on the developerWorks Web site, at http://www.ibm.com/developerworks/java/jdk/security/index.html.

# Keytool

Keytool is a key and certificate management utility for managing public and private key pairs and associated certificates.

You can use Keytool to administer your public and private key pairs and associated certificates. These keys and certificates can be used for self-authentication, or data integrity and authentication services.

Keytool can also administer secret keys that are used in symmetric encryption/decryption, for example, DES.

Keytool stores the keys and certificates in a keystore.

## Documentation

The Keytool - Key and Certificate Management Tool Guide and Javadoc information are on developerWorks, at http://www.ibm.com/developerworks/java/jdk/security/index.html.

# Notices

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 described in this document. The furnishing of this document does not grant 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 character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

- Intellectual Property Licensing
- Legal and Intellectual Property Law
- IBM Japan Ltd.
- 1623-14, Shimotsuruma, Yamato-shi
- Kanagawa 242-8502 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 publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication 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 measurements 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.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.

Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. _enter the year or years_.

If you are viewing this information softcopy, the photographs and color illustrations may not appear.

## Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml.

Intel is a trademark of Intel Corporation in the United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other company, product and service names may be trademarks or service marks of others.