Security has been a major design goal and a key architectural feature of Java™ technology since its inception. The security capabilities of Java technology have two roots:

• The Java Runtime Environment (JRE), a ready-made platform on which applications can run in a secure fashion
  
  
• Security tools and services APIs, which provide a security infrastructure by serving as building blocks in developing secure systems

Several Java security components are responsible for providing security services. The components were developed based on a set of design principles -- implementation independence and interoperability, algorithm independence and extensibility -- that were first introduced in the Java Cryptography Architecture (JCA) framework. They all follow the JCA framework architecture, which is a service provider-based architecture that allows you to plug in multiple security mechanisms through the Service Provider Interface (SPI). But the components have different purposes and security operations, and each one supports a different set of algorithms and protocols.

Each Java Software Development Kit (SDK) has a default list of security providers preregistered in the Java security configuration located in <java-home >/jre/lib/security/java.security. You simply request a particular security service through Java APIs. This shields you from the complexity of the underlying implementation of the security operations, while allowing the Java security components to support an increasing number of algorithms and security mechanisms.

The IBM® 1.4.2 SDK is the most comprehensive security offering available from IBM for the Java 2 platform. It differs from the Sun 1.4.2 JDK in that IBM has implemented providers for all the Java security components. Previous versions of the JRE (1.2.x and 1.3.x) came with a default Sun provider. In the IBM 1.4 environment, a number of new providers replace that default provider.

IBM's Java security configuration includes four default security providers and several optional providers you can register and configure to use for your applications. We'll go through each of the providers in more detail and highlight the differences between the IBM and Sun providers.

The IBMJSSE provider

The Java Secure Socket Extension (JSSE) provides a standard Java API for encapsulating the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols, including functionality for data encryption, server authentication, message integrity, and optional client authentication. JSSE users can write to a standard API without worrying about the underlying SSL/TLS implementation. JSSE also supports HTTP encapsulated in the SSL protocol (HTTPS), which allows access to data such as Web pages using HTTPS. JSSE was an optional package to Java 1.2 and 1.3 and has been integrated into the JDK since Version 1.4. In the IBM 1.4.2 SDK, the JSSE framework allows additional JSSE providers; the Sun JSSE framework doesn't. The IBM SDK comes preinstalled with two additional JSSE providers -- IBMJSSEProvider2 and IBMJSSEFIPSProvider, which we'll discuss later in this article. IBMJSSE is the preregistered provider, and IBMJSSEProvider2 and IBMJSSEFIPSProviders are optional.

The IBMJSSE provider supports the following standard algorithms and types:

• SSLContext: SSLv2, SSLv3, SSL, TLSv1, TLS, and SSL_TLS
• KeyManagerFactory: IbmX509
• TrustManagerFactory: IbmX509
• Cipher suites:
  • SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_AES_128_CBC_SHA, SSL_DH_anon_WITH_AES_256_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, and SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA

Differences from the Sun version

The JSSE documentation includes the complete set of differences between the IBM and Sun JSSE implementations (see Resources). The major differences are detailed below:

• The IBM JSSE provider's default TrustManager implementation doesn't allow anonymous cipher suites. However, you can override the default implementation by writing a TrustManager class that does allow anonymous cipher suites.
  
  
• The IBM JSSE implementation verifies the entire server or client certificate chain, including trusted certificates. For example, if a trusted certificate has expired, the handshake fails even though the expired certificate is trusted. Sun's JSSE verifies the certificate chain up to the trusted certificate. Verification stops when it reaches a trusted certificate, so the trusted certificate and beyond are not verified. Therefore, the Sun JSSE trusts a certificate chain with an expired trusted certificate.
  
  
• The IBM JSSE implementation requires that you have the trusted certificate in your truststore in order to trust the peer's certificate chain. If you have the private key in your keystore, the Sun implementation considers a certificate trusted.
  
  
• The IBM JSSE implementation requires a debug JAR for complete tracing. You turn tracing on with javax.net.debug=true.
  
  
• The IBM JSSE provider doesn't include the new TrustManager support that implements rules for certificate chain path validation that Sun added to 1.4.2. (The new IBMJSSEProvider2 does contain this support.)

Back to top

The IBMJCE provider

The JCA was introduced in JDK 1.1, which includes APIs for digital signatures and message digests. In subsequent JDK releases, the Java Cryptography Extension (JCE) extends the JCA to include APIs for various cryptographic functions, including encryption, key exchange, and Message Authentication Code (MAC). JCE was previously an optional package (extension); it has been integrated into the Java 2 SDK since Version 1.4. IBMJCE is the IBM provider for the JCA and JCE framework. It is fully compatible with Sun's JCE 1.2.2. The complete set of supported algorithms are listed below:

• 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, and MD2 with RSA signatures
  • SHA1 with DSA signature
• Message digest algorithms
  • SHA1
  • SHA2
  • SHA3
  • SHA5
  • MD5
  • MD2
• MAC
  • Hmac/SHA1
  • Hmac/MD5
• Key agreement algorithm
  • DiffieHellman
• Random number generation algorithms
  • IBMSecureRandom
  • IBM SHA1PRNG
• Key Store
  • JCEKS
  • JKS
  • PKCS12KS
  • JCERACFKS

Differences from the Sun version

The IBMJCE provider replaces the Sun sun.security.provider.Sun, com.sun.rsajca.Provider, and com.sun.crypto.provider.SunJCE providers. IBM supports additional cryptographic algorithms not available in the Sun implementation.

Back to top

The IBMJGSS provider

The Java Generic Security Service (JGSS) API has been included in the JDK since version 1.4. It provides a generic mechanism for defining authentication and secure message exchange that isn't bound by any specific network protocol or security mechanism. The API, which was developed and standardized by the Internet Engineering Task Force (IETF) standards body, is in the org.ietf.jgss package. The API does not have an SPI. Given the need to allow various General Security Service (GSS) mechanisms -- such as SPNEGO and SPKM -- to plug in, IBM has its own JGSS SPI in an internal framework that isn't public to end users. The IBMJGSSProvider is an IBM provider for the JGSS framework. It uses Kerberos as the default mechanism to provide authentication, message confidentiality, and message integrity (see Resources).

Difference from the Sun version

The format of the parameters passed to the kinit, ktab, and klist Java tools is different from the format for Sun's equivalent tools.

Back to top

The IBMCertPath provider

The Java Certification Path API was introduced in JDK 1.4 for creating, building, and validating certification paths (also known as certificate chains). IBMCertPath is the IBM provider for the Java Certification Path API. It includes the following implementations:

• CertificateFactory: A certificate factory for generating X.509 certificates, Certificate Revocation Lists (CRLs), and CertPath objects with PKCS7 and PkiPath encodings
  
  
• CertPathValidator: A certificate-path validator for the PKIX (RFC 3280) algorithm
  
  
• CertPathBuilder: A certificate-path builder for PKIX
  
  
• CertStore: A Collection-type certificate store for retrieving certificates and CRLs from Collection and a Lightweight Directory Access Protocol (LDAP)-type certificate store for retrieving certificates and CRLs from LDAP directories using the PKIX LDAP V2 Schema (RFC 2587)

Difference from the Sun version

Sun does not have a separate provider for the Certification Path API; its implementation is part of the default Sun provider.

Back to top

The IBMJSSE2 provider

IBM 1.4.2 Java SDK includes a new JSSE provider called IBMJSSE2. It isn't preregistered with the Java runtime. You can add it statically to the provider list in the Java security file by appending this line:

java.security.provider.5=com.ibm.jsse2.IBMJSSE2

You also can register it programmatically by calling one of the java.security.Provider methods, such as java.security.Provider.addProvider(new com.ibm.jsse2.IBMJSSEProvider2()).

The IBMJSSE2 provider has the same basic functionality as the IBMJSSE provider. The new provider doesn't support the original IBMJSSE provider's previously deprecated com.ibm.net.ssl classes, which are now in javax.net.ssl. The new provider includes a number of improvements. Most significantly, it can use hardware cryptographic accelerators' potential performance improvements and use hardware cryptographic cards as keystores for greater flexibility in key and trust management. In addition to the simple X.509-based TrustManager that the IBMJSSE provider supports, it supports a second, PKIX-compliant TrustManager that uses CertPath services to build and validate certificate chains. Unlike the IBMJSSE provider, IBMJSSE2 does not contain internal cryptographic functionality. It uses cryptographic services from the IBM JCE providers (such as IBMJCE and IBMPKCS11Impl). Because IBMJSSE2 doesn't have any internal cryptographic functionality, JSSE no longer needs to be Federal Information Processing Standards (FIPS) certified. IBMJSSE2 requires only JCE to be FIPS certified. Serviceability and traces have been significantly improved with the new JSSE2 provider. Because SSL Version 2 is considered a less secure protocol and unlikely to be used today, this provider does not support the SSLv2 protocol.

Differences from the Sun version

The IBMJSSE2 documentation includes the complete set of differences between the IBM and Sun JSSE implementations (see Resources). The major differences are:

• The IBMJSSEProvider2 default TrustManager implementation does not allow anonymous cipher suites. However, you can override the default implementation by writing a TrustManager class that does allow anonymous cipher suites.
  
  
• The IBMJSSEProvider2 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, so the trusted certificate and beyond are not verified. Therefore, the Sun JSSE trusts a certificate chain with an expired trusted certificate.

The documentation also details the differences between IBM's original JSSE provider and this new JSSE provider.

Back to top

The IBMPKCS11Impl provider

The IBMPKCS11Impl provider is new for the IBM 1.4.2 Java SDK. IBMPKCS11Impl uses the JCE and JCA frameworks to add the ability to use hardware cryptography through the Public Key Cryptographic Standards #11 (PKCS #11) standard. It is not preregistered with the Java runtime. You can add it statically to the provider list the in java.security file by appending a line such as:

security.provider.5=com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl

You also can register it programmatically by using the methods of the java.security.Security class, such as java.security.Security.addProvider("com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl").

The provider enables access to the following variable cryptographic functions and algorithms through the hardware device:

• Cipher-DES, Triple DES, RSA
• Signature- DSA, RSA
• Message Digest- MD2, MD5, SHA1
• KeyPairGenerator- DSA, RSA
• KeyGenerator-DES, TripleDES
• RandomNumberGenerator-PKCS11DeviceRNG, IBMSecureRandom
• CertificateFactory-X509
• KeyStore-PKCS11IMPLKS

This provider supports the following devices:

• IBM 4758 PCI Cryptographic Coprocessor
• IBM e-business Cryptographic Accelerator
• nCipher nFast
• IBM Security Kit SmartCard
• Gem Plus Smart Cards
• Rainbow Cryptoswift
• Rainbow ikey 2000
• nCipher nForce
• Chrysalis Luna HSM
• Eracom Orange

The list of supported algorithms contains the maximum possible number of functions that this provider allows an application to use. The actual list of functions might be smaller, depending on the hardware device you use. The hardware device might also require that certain attributes be associated with each key, depending on the device. Read the documentation about your hardware device to know its restrictions, requirements, and the algorithms it provides. And see "Card Observations" in the IBMPKCS11Impl documentation for more information about some hardware devices and their use with this provider (see Resources).

Difference from the Sun version

The Sun version of JDK Version 1.4.2 doesn't provide hardware cryptographic support.

Back to top

FIPS cryptographic modules

The IBM 1.4.2 Java SDK includes two FIPS 140-2 compliant modules for JCE and JSSE called, IBMJCEFIPS and IBMJSSEFIPS. The IBMJCEFIPS module is implemented as a JCE provider to support FIPS-approved cryptographic operations through JCE framework APIs. The IBMJSSEFIPS module is implemented as a JSSE provider to support the FIPS-approved TLS cipher suites through the JSSE framework APIs. An application that uses these two providers complies with FIPS 140-2 requirements when properly configured. The providers are not preregistered with Java runtime. You can add them to the provider list in the java.security file by appending lines such as:

security.provider.5=com.ibm.crypto.fips.provider.IBMJCEFIPS
security.provider.6=com.ibm.crypto.fips.provider.IBMJSSEFIPSProvider

You also can register them programmatically by using the methods of the java.security.Security class, such as java.security.Security.addProvider("com.ibm.crypto.fips.provider.IBMJCEFIPS").

Difference from the Sun version

The Sun version of JDK Version 1.4.2 does not have FIPS-approved cryptographic modules.

Back to top

JAAS LoginModule

Java Authentication and Authorization Service (JAAS) is a framework for providing authentication and authorization to runtime resources. The JAAS client applications write to the LoginContext API, and authentication service providers implement the LoginModule interface. The LoginContext is responsible for reading the configuration file and installing the correct LoginModules. IBM versions of JAAS provide platform-specific login modules in the com.ibm.security.auth.module package that import a user's particular platform-specific Principal information and associate the information with the Subject. IBM JAAS supports Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003. IBM JAAS also supports z/OS, various Linux flavors (Linux on Intel architecture, Linux on iSeries, Linux on pSeries, and Linux on zSeries), and AIX, providing different login modules to use on these platforms:

• z/OS: OS390LoginModule
• 32-bit Windows: NTLoginModule, NTLoginModule2000, NTActiveLoginModule, and NTActiveLoginModule2000
• 64-bit Windows : Win64LoginModule and Win64ActiveLoginModule
• Linux: LinuxLoginModule
• 32-bit AIX: AIXLoginModule and AIXLoginModule2000
• 64-bit AIX: AIX64LoginModule

The IBM version of JAAS for Windows and z/OS contains an additional function that Sun does not have called active login. Because Windows and z/OS have an extensive security infrastructure, it is important on servers to allow a Java program to log in as a particular user and run with the underlying operating system knowing the security identity on a particular thread. Without this extended support, JAAS would allow the Java program to know who the user is, strictly on a Java level. With this extended support, Java programs can log in as different users and have even non-Java programs (such as the Windows kernel) enforce security appropriately. The following classes contain the additional support:

• com.ibm.security.auth.NTThreadSubject on Windows or com.ibm.security.auth.OS390ThreadSubject on z/OS. This class is the gateway to changing identities on a operating-system thread level.
  
  
• com.ibm.security.auth.module.NTActiveLoginModule on Windows or com.ibm.security.auth.module.OS390LoginModule on z/OS. This class is specified in the login configuration file. If you construct a LoginContext using a string name that calls this LoginModule, and you supply a CallbackHandler that can supply a userid and password suitable for the Windows computer, you can log in. The OS390LoginModule for z/OS provides a default login module supporting basic authentication with the z/OS Security Services, SAF (RACF).

Differences from the Sun version

IBM's JAAS contains the active login function and provides platform-specific login modules.

Back to top

Conclusion

Security is a major technical challenge when you're building mission-critical software applications, especially those using Internet-based technologies. As we've shown, the IBM 1.4.2 Java SDK provides a rich set of implementations of security infrastructure through several key Java security components, with unique capabilities available only in the IBM providers. They give you a solid foundation for developing and deploying security-sensitive, end-to-end enterprise applications.

Resources

• Learn more about and download the IBM developer kits for the Java platform.
  
  
• For more information on Java security, visit IBM developer kit: Security information.
  
  
• Visit the IBM JSSE documentation page for JSSE reference guide, Javadocs, and samples.
  
  
• Visit the IBM JCE documentation page for user guide, Javadocs, and samples.
  
  
• Visit the IBM JGSS documentation page for JGSS user guide, developer guide, Javadocs, and samples.
  
  
• Learn more about Kerberos, the default authentication mechanism for the IBMJGSSProvider, from A Kerberos primer (developerWorks, November 2001).
  
  
• Visit the IBM CertPath documentation page for CertPath user guide, Javadocs, and samples.
  
  
• Visit the IBM JSSE2 documentation page for JSSE2 reference guide, Javadocs, and samples.
  
  
• For details on the TLS version 1 protocol, see IETF Request for Comments (RFC) 2246, The TLS Protocol Version 1.0.
  
  
• Visit the IBMPKCS11Impl documentation page for IBMPKCS11Impl user guide and Javadocs.
  
  
• For details on using the IBMPKCS11Impl hardware cryptographic provider, see How to use the IBM Java hardware cryptographic providers.
  
  
• For details on how to use the IBM FIPS providers, see Using the IBM Java FIPS-approved providers IBMJSSEFIPSProvider and IBMJCEFIPS.
  
  
• Visit the IBM-certified JCE FIPS documentation page for the security policy and Javadocs.
  
  
• Visit the IBM certified JSSE FIPS documentation page for JSSE FIPS security policy.
  
  
• For the JAAS documentation, which includes Javadocs, user guide, developer guide, and samples, choose the appropriate platform from the IBM 1.4.2 developer kit: Security information page.
  
  
• Find hundreds more Java technology resources on the developerWorks Java technology zone.
  
  
• Browse for books on these and other technical topics.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The IBMJSSE provider
• The IBMJCE provider
• The IBMJGSS provider
• The IBMCertPath provider
• The IBMJSSE2 provider
• The IBMPKCS11Impl provider
• FIPS cryptographic modules
• JAAS LoginModule
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Java on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers