IBM security providers An overview by lfsmj2010

VIEWS: 1 PAGES: 6

									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.

								
To top