Date: 2004-08-26

# IBM SDK for Linux platforms, Java 2 Technology Edition, Version 1.4.2, Service Refresh 1

# Security Guide

# Copyright information

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 Java Secure Socket Extension (JSSE) IBM JSSE2 Provider
- |IBM PKCS11 Implementation Provider
- |IBM Java JCE FIPS Provider
- |IBM Java JSSE FIPS Provider

and to all subsequent releases and modifications 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, 2004. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

# 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(TM) APIs (except iKeyman). The |security components contain the IBM(R) implementation of various security |algorithms and mechanisms.

|

If your JVM ships with a native jpkcs library, IBM's security components can take advantage of hardware cryptography |through the provider IBMPKCS11Impl. IBMPKCS11Impl is implemented as a provider |of JCE, so that existing applications that use JCE software (such as IBMJCE) |can take advantage of a hardware-capable PKCS#11 environment. IBMPKCS11Impl |interacts with different hardware devices to provide:

|

|
- Message digest,
|
- Data encryption and decryption,
|
- Digital signature generation and verification,
|
- Random number generation and key generation through JCE architecture.
|
- PKCS#11 key and certificate management through iKeyman,

IBMPKCS11Impl enables JSSE to take advantage of hardware cryptography |through the IBMJSSE2 provider (new in v1.4.2.).

|

The SDK v.1.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 three providers: IBMJCE is the pre-registered default |provider; IBMPKCS11Impl and IBMJCEFIPS are optional.

|

JSSE is the Java 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 IBM's secure random |number generator, IBMSecureRandom, which is a real Random Number Generator. |SHA1PRNG, also part of IBM JCE, 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 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".

Technical changes made to this guide for Version 1.4.2 and for Version 1.4.2, Service Refresh 1, other than minor or obvious ones such as updating "1.4.1" to "1.4.2", are indicated in red when viewing in HTML or in a color-printed copy and by vertical bars to the left of the changes.

# Contents

Copyright information
Preface
| |
General Information about IBM security providers
iKeyman tool
What's new?
Documentation
Java Authentication and Authorization Service (JAAS) V2.0 for Linux
Differences between IBM and Sun versions of JAAS
What has been added for the IBM 32-bit SDK for Linux on Intel architecture
Documentation
Java Certification Path (CertPath)
Differences between IBM and Sun versions of CertPath
What's new?
Documentation
Java Cryptography Extension (JCE)
Differences between IBM and Sun versions of JCE
What's new?
Documentation
Java Generic Security Service (JGSS)
Differences between IBM and Sun versions of JGSS
What's new?
Documentation
IBM Java Secure Socket Extension (IBMJSSE)
Anonymous ciphers
Using hardware cryptographic adapters with JSSE (zLinux only)
Differences between IBM and Sun versions of JSSE
What's new?
Documentation
| |
IBMJSSE2 Provider
| |
Differences between the IBMJSSE Provider and the IBMJSSE2 Provider
| |
Differences between the IBMJSSE2 Provider and Sun's version of JSSE
| |
What's new?
| |
Documentation
| |
IBMPKCS11Impl Provider
| |
Differences between IBM and Sun versions of IBMPKCS11Impl
| |
What's new?
| |
Documentation
| |
IBMJCEFIPS Provider
| |
Differences between IBM and Sun versions of IBMJCEFIPS
| |
What's new?
| |
Documentation
| |
IBMJSSEFIPS Provider
| |
Differences between IBM and Sun versions of IBMJSSEFIPS
| |
What's new?
| |
Documentation
Notices
Trademarks
| | |

# General Information about IBM security providers

|

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.crypto.pkcs11impl.provider.IBMPKCS11Impl
|
- com.ibm.jsse2.IBMJSSEProvider2

| |
Notes:
|

|
1. 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. |
|
2. 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: |
   |
   1. Add the IBMJSSE2 provider before the IBMJSSE provider in the provider |list.
   |
   2. 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`.
   |
|
3. The com.ibm.crypto.pkcs11.provider.IBMPKCS11 |provider is intended for use by iKeyman only and not by other applications. |The only way to add this provider to the provider list, is to follow the instructions |in the iKeyman documentation. |
|
4. A java.security.NoSuchAlgorithmException might be thrown if an application |tries to add and initialize the com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl |provider if there is one in the provider list already.
|

# iKeyman tool

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
- |Store and retrieve keys and certificates to and from cryptographic |hardware on your system

Note:
| |
(Linux zSeries only) The IBMPKCS11Impl |provider on Linux zSeries (31 and 64-bit) must not be in the provider list |when invoking iKeyman.

## What's new?

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

## Documentation

Go to http://www.ibm.com/developerworks/java/jdk/security/index.html to download the file iKeymanDocs.zip that contains the iKeyman documentation.

Table 1. Contents of iKeymanDocs.zip
File | Contains
--- | ---
ikmuserguide.pdf | iKeyman User Guide

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

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

## Differences between IBM and Sun versions of JAAS

The IBM version of JAAS for Linux differs from the Sun version of JAAS in the following way:

- The com.sun.* packages have been moved to com.ibm.* packages.

## What has been added for the IBM 32-bit SDK for Linux on Intel architecture

The original release of JAAS for Linux and the Java 2 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 both the original set and the new set of principal classes. Also included is a new login module called com.ibm.security.auth.module.LinuxLoginModule2000. This new login module parallels LinuxLoginModule in functionality, 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 and future versions of JAAS released for the SDK version 1.4.0.

If you migrate applications to the new set of principals, most of the changes you will encounter will be in JAAS policy and configuration files rather than in the applications. Refer to the following table for more information.

Table 2. New Principal 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. The login module is found in the com.ibm.security.auth.module package. Check the JAAS API documentation (javadocs) 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";
    };

would be 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";
    };

## Documentation

For detailed information, including API documentation and samples, download and expand the file JaasDocs.zip from the developerWorks Web site at http://www.ibm.com/developerworks/java/jdk/security/index.html.

JaasDocs.zip contains the following files:

Table 3. Contents of the compressed files.
File | Contains
--- | ---
<platform_name>/api.html | JAAS API reference guide
<platform_name>/login.html | Authentication module reference guide
<platform_name>/HelloWorld.tar | Sample code
<platform_name>/apidocs/index.html | JAAS API information generated by javadoc

where <platform_name> is either LinuxIA32, LinuxIA64, LinuxPPC32, LinuxPPC64 or Linux390.

# 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 Sun versions of CertPath

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. IBM's provider recognizes both |HTTP and LDAP URLs.|

## What's new?

|The following changes were added in v1.4.2, |in SR1:

|

|
- The performance of the IBM CertPath provider has been improved.
|
- Limited support for the CRL Distribution Points extension has been added.

|The following change was added in v1.4.2:

|

|
- IBM LDAP CertStore provides caching to cache lookups.

|The following change was added in v1.4.1, in SR1:

|

|
- The trusted certificate that acts as TrustAnchor can be an X.509 v1 certificate.

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.

## 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. Download and expand the file certpathDocs.zip.

Table 4. Contents of certpathDocs.zip
File | Contains
--- | ---
samples/ | Sample source code
API_users_guide.html | API user guide
api/ | CertPath API reference guide

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

## Differences between IBM and Sun versions of JCE

The IBM JCE implementation is in the com.ibm.* packages. Sun's implementation is in the com.sun.* 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
    - RSA encryption/decryption
    - DES
    - Triple DES
    - Mars
    - RC2
    - RC4
    - Seal
    - 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
  - 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)
    - Hmac/SHA1
    - Hmac/MD5
  - Key agreement algorithm
    - DiffieHellman
  - Random number generation algorithms
    - IBMSecureRandom
    - IBM SHA1PRNG
  - Key Store
    - JCEKS
    - JKS
    - PKCS12KS

## What's new?

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

## 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. Download and expand the file jceDocs.zip.

Table 5. Contents of jceDocs.zip
File | Contains
--- | ---
api/ | JCE API reference guide
samples/ | JCE sample source code
api_users_guide.html | JCE reference guide
CryptoSpec.html | JCA reference guide
HowToImplAProvider.html | Guide to implementing a JCE provider
JCEAlgorithms.java | Utility program to list all supported JCE algorithms and aliases
MyProvider.java | Example provider source file

# Java Generic Security Service (JGSS)

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.

## Differences between IBM and Sun versions of JGSS

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.

## What's new?

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

## 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. Download and expand the file jgssDocs.zip.

Table 6. Contents of jgssDocs.zip
File | Contains
--- | ---
api/ | JGSS API reference guide
samples/ | JGSS Sample source code
developers_guide.jgss.ibm.html | JGSS Developers reference guide
users_guide.jgss.ibm.html | JGSS User guide

# IBM Java Secure Socket Extension (IBMJSSE)

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.

## Anonymous ciphers

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.

## Using hardware cryptographic adapters with JSSE (zLinux only)

In a user application you can use a hardware token (that is, hardware cryptographic adapter), for Trusted Certs or Private Certs, in a user application by specifying the token type "PKCS#11" and token library name in a call to the com.ibm.jsse.SSLContext class init method:

    public final void init(java.lang.String tokenType,
                           java.lang.String token,
                           java.lang.String password)
                    throws java.security.KeyManagementException

For example:

    SSLContext context = ...;
    context.init("PKCS#11", "/usr/lib/pkcs11/PKCS_11.so ", "password");

To specify a specific slot, the slot number should be specified at the end of the token. For example, using slot # 2:

    SSLContext context = ...;
    context.init("PKCS#11", "/usr/lib/pkcs11/PKCS_11.so:2", "password");

## Differences between IBM and Sun versions of JSSE

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". |
- |IBM's KeyManagerFactory is called "IbmX509". |
- |IBM's TrustManagerFactory is called "IbmX509". |
- |IBM's HTTPS protocol handler is called "com.ibm.net.ssl.www.protocol.Handler". |
- |IBM and Sun support different ciphers. |
- |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. IBM's implementation supports the SSL v2 protocol. You can use |IBM's 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(). |
- |IBM's JSSE framework allows the addition of other JSSE providers. |Sun's framework currently does not. |
- |IBM's JSSE implementation uses an internal cryptographic |provider. |
- |IBM's 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. |
- |IBM's 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. |
- |IBM's 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. |
- |IBM's 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 IBM's JSSE implementation, tracing is turned on by `javax.net.debug=true`. Complete tracing requires the debug version of |IBMJSSE. |
- |IBM's 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 IBM's 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. |
- | IBM's 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. |

## What's new?

|The following changes are added in v1.4.2:

|

|
- The IBMJSSE Provider supports several additional cipher suites; they include |cipher suites using AES as a symmetric cipher and a new ephemeral Diffie-Hellman |cipher with RSA authentication. For more information, see the JSSE documentation |at http://www.ibm.com/developerworks/java/jdk/security/index.html.

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.

## Documentation

For detailed information, including API documentation and samples, see http://www.ibm.com/developerworks/java/jdk/security/index.html. Download and expand the file JSSEDocs.zip.

Table 7. Contents of the JSSEDocs.zip.
File | Contains
--- | ---
api/ | JSSE API reference guide
samples/ | JSSE Sample source code
JSSERefGuide.html | JSSE Reference guide

| | |

# IBMJSSE2 Provider

|

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 IBM's JCE providers, IBMJCE, IBMJCEFIPS, IBMJCE4758, |and IBMPKCS11Impl 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 can be configured to use hardware cryptographic accelerators' |potential performance improvements and to use hardware cryptographic cards |as keystores for greater flexibility in key and trust management. The IBMJSSE2 |Provider uses the IBMPKCS11Impl Provider to provide hardware cryptographic support.

|

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.

| |

## Differences between the IBMJSSE Provider and the IBMJSSE2 Provider

|

The IBMJSSE Provider and the IBMJSSE2 Provider differ in the following |ways:

|

|
- The IBMJSSE2 Provider is called "com.ibm.jsse2.IBMJSSEProvider2". It is |not preregistered 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. 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 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. |
|

| |

## Differences between the IBMJSSE2 Provider and Sun's version of JSSE

|

The IBMJSSE2 Provider differs from the Sun JSSE in the following ways:

|

|
- |The IBM JSSE provider is called "com.ibm.jsse2.IBMJSSEProvider2".|
|
- |IBM's KeyManagerFactory is called "IbmX509". |
  |
|
|
- |IBM's TrustManagerFactory is called "IbmX509" or "IbmPKIX". |
  |
|
|
- |IBM's 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 specifying |the "SSLv2Hello" protocol. A server side connection always accepts SSLv2Hello. |You can use IBM's 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 |
  |
|
|
- |IBM's JSSE framework allows the addition of other JSSE providers. |Sun's framework currently does not. |
  |
|
|
- |IBMJSSE2 uses IBM JCE Providers only for its cryptography |
  |
|
|
- |IBM's 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. |
  |
|
|
- |IBM's 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. |
  |
|
|
- |IBM's 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. |
  |
|
|
- |IBM's 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 IBM's 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. |
  |
|
|
- | IBM's 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. |
  |
|
|

| |

## What's new?

|

The IBMJSSE2 Provider is new for v1.4.2.

| |

## Documentation

|

For detailed information, including API documentation and samples, see http://www.ibm.com/developerworks/java/jdk/security/index.html. Download and expand the file JSSE2Docs.zip.

| |

Table 8. Contents of the JSSE2Docs.zip.
|File | | Contains |
--- | ---
|api/ | | JSSE2 API reference guide |
|samples/ | | JSSE2 Sample source code |
|JSSE2RefGuide.html | | JSSE2 Reference guide |
|

| | |

# 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 Cryptogaphic Standards #11 (PKCS |#11) standard. This new provider takes advantage of hardware cryptography |within the JCE architecture and improves security and performance with minimal |changes to existing Java applications.

|

The IBMPKCS11Impl provides:

|

|
- Message Digest using the MD2, MD5, and SHA-1 algorithms.
|
- Signature and KeyFactory classes.
|
- The symmetric algorithms DES, triple DES (also known as DESede), the asymmetric |algorithms RSA encryption, decryption with zero padding, and PKCS padding.
|
- Digital signature and verification using the RSA and DSA algorithms.
|
- Random number generation, key generation by key factories, key/certificate |generation and key/certificate management (using iKeyman).

|

PKCS#11 is a standard that provides a common application interface to cryptographic |services on various platforms through several hardware cryptographic devices. |The following devices are supported by this provider:

|

|
- IBM 4758
|
- IBM 4960 (IBM LEEDS Lite)
|
- nCipher nFast
|
- IBM Security Kit SmartCard
|
- Gem Plus Smart Cards
|
- Rainbow Cryptoswift
|
- Rainbow ikey 2000
|
- nCipher nForce
|
- Chrysalis Luna HSM
|
- Eracom Orange

| |
Notes:
|

|
1. (Linux zSeries only) The IBMPKCS11Impl provider on Linux zSeries must be listed directly after IBMJCE.
|
2. (Linux zSeries only) The IBMPKCS11Impl provider on Linux zSeries (31 and |64-bit) must not be in the provider list when invoking |iKeyman.
|

| |

## Differences between IBM and Sun versions of IBMPKCS11Impl

|

Sun does not provide IBMPKCS11Impl.

| |

## What's new?

|

The IBMPKCS11Impl Provider is new for v1.4.2.

| |

## Documentation

|

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

| | |

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

| |

## Differences between IBM and Sun versions of IBMJCEFIPS

|

Sun does not provide IBMJCEFIPS.

| |

## What's new?

|

The IBMJCEFIPS Provider is new for v1.4.2.

| |

## Documentation

|

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

| | |

# IBMJSSEFIPS Provider

|

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

| |

## Differences between IBM and Sun versions of IBMJSSEFIPS

|

Sun does not provide IBMJSSEFIPS.

| |

## What's new?

|

The IBMJSSEFIPS Provider is new for v1.4.2.

| |

## Documentation

|

For detailed information, including API documentation and Security Policy, |see 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 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.

## Trademarks

IBM and zSeries 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 and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

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