VIEWS: 1 PAGES: 6 POSTED ON: 1/31/2013
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 fashionSecurity tools and services APIs, which provide a security infrastructure by serving as building blocks in developing secure systemsSeveral 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_TLSKeyManagerFactory: IbmX509TrustManagerFactory: IbmX509Cipher 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_SHADifferences 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 algorithmsAESRSA encryption/decryptionDESTriple DESMarsRC2RC4SealPBE with MD2 and DESPBE with MD2 and Triple DESPBE with MD2 and RC2PBE with MD5 and DESPBE with MD5 and Triple DESPBE with MD5 and RC2PBE with SHA1 and DESPBE with SHA1 and TripleDESPBE with SHA1 and RC2PBE with SHA1 and 40-bit RC2PBE with SHA1 and 128-bit RC2PBE with SHA1 and 40-bit RC4PBE with SHA1 and 128-bit RC4PBE with SHA1 and 2-key Triple DESPBE with SHA1 and 3-key Triple DESSignature algorithmsSHA1 with RSA, MD5 with RSA, and MD2 with RSA signaturesSHA1 with DSA signatureMessage digest algorithmsSHA1SHA2SHA3SHA5MD5MD2MACHmac/SHA1Hmac/MD5Key agreement algorithmDiffieHellmanRandom number generation algorithmsIBMSecureRandomIBM SHA1PRNGKey StoreJCEKSJKSPKCS12KSJCERACFKSDifferences 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 encodingsCertPathValidator: A certificate-path validator for the PKIX (RFC 3280) algorithmCertPathBuilder: A certificate-path builder for PKIXCertStore: 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.IB MPKCS11Impl"). The provider enables access to the following variable cryptographic functions and algorithms through the hardware device: Cipher-DES, Triple DES, RSASignature- DSA, RSAMessage Digest- MD2, MD5, SHA1KeyPairGenerator- DSA, RSAKeyGenerator-DES, TripleDESRandomNumberGenerator-PKCS11DeviceRNG, IBMSecureRandomCertificateFactory-X509KeyStore-PKCS11IMPLKSThis provider supports the following devices: IBM 4758 PCI Cryptographic CoprocessorIBM e-business Cryptographic AcceleratornCipher nFastIBM Security Kit SmartCardGem Plus Smart CardsRainbow CryptoswiftRainbow ikey 2000nCipher nForceChrysalis Luna HSMEracom OrangeThe 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.IBMJCEFI PS"). 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: OS390LoginModule32-bit Windows: NTLoginModule, NTLoginModule2000, NTActiveLoginModule, and NTActiveLoginModule200064-bit Windows : Win64LoginModule and Win64ActiveLoginModuleLinux: LinuxLoginModule32-bit AIX: AIXLoginModule and AIXLoginModule200064-bit AIX: AIX64LoginModuleThe 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.
Pages to are hidden for
"IBM security providers An overview"Please download to view full document