Getting started with RSA BSAFE® Share For JAVA™ Platform - EMC ...

RSA BSAFE ® Share for Java Platform 1.1
Upgrading
RSA, The Security Division of EMC,
July 16, 2009
Version 1.0, July 16, 2009

Introduction to Presentation
This presentation describes how to upgrade an application
to and from using RSA BSAFE ® Share for Java TM
Platform (Share for Java).
2

Objective
As a result of this presentation you will be able to upgrade:
– Sun’s JRE 6.0 to Share for Java
– Share for Java to RSA BSAFE® Crypto-J and RSA BSAFE®
SSL-J.
3

Agenda
Upgrading from Sun’s JRE 6.0
Upgrading to RSA BSAFE® Crypto-J and RSA BSAFE®
SSL-J
4

Upgrading
Sun’s JRE 6.0 to Share for Java
5

Upgrading: Sun’s JRE 6.0 to Share for Java
Agenda
Agenda
– Class path and provider registration
– Algorithm support
– Key stores
– Recommended code changes
6

Upgrading: Sun’s JRE 6.0 to Share for Java
Class Path and Provider Registration
shareCrypto.jar and shareTLS.jar must be added directly or
indirectly to the class path.
– If static registration is to be used:
• shareCrypto.jar and shareTLS.jar files must be copied to the
jre/lib/ext directory.
• If LDAP is to be used, openldap.jar must be copied to the
jre/lib/ext directory.
• com.rsa.jsafe.provider.JsafeJCE and
com.rsa.jsse.JsseProvider must be added to the provider list in
the jre/lib/security/java.security file.
– If dynamic registration is to be used:
• shareCrypto.jar and shareTLS.jar files must be copied to the
jre/lib/ext directory or added to the class path.
• If LDAP is to be used, openldap.jar must be copied to the
jre/lib/ext directory or added to the class path.
7

Upgrading: Sun’s JRE 6.0 to Share for Java
Algorithm Support
Applications which rely on algorithms not supported by
Share for Java need to be modified to use alternative
algorithms.
8

Upgrading: Sun’s JRE 6.0 to Share for Java
Algorithm Support: JKS KeyStores
JKS format java.security.KeyStore objects are not
supported by Share for Java.
– Upgrade Path: Copy all private keys and certificate chains out of
the JKS KeyStore and put them into a PKCS #12 KeyStore.
• Using Sun JRE 6.0...
• Statically register com.rsa.jsafe.provider.JsafeJCE from
shareCrypto.jar in first position.
• Execute the command line:
keytool -importkeystore –v
-srckeystore .jks -srcstoretype JKS -srcstorepass
-destkeystore .p12 -deststoretype P12 -deststorepass
where is the file to be converted and is the password.
9

Upgrading: Sun’s JRE 6.0 to Share for Java
Recommended Code Changes
The following slides list some small code changes which
will improve the security of your system. The changes fall
into the categories:
– Use of java.security.SecureRandom
– Use of javax.net.ssl.SSLContext
– Use of javax.net.ssl.SSLServerSocket and
javax.net.ssl.SSLSocket
10

Upgrading: Sun’s JRE 6.0 to Share for Java
Recommended Code Changes: SecureRandom
Issue:
– No strong PRNG algorithms are available in Sun JRE 6.0. If a
SecureRandom is being explicitly created, it won’t be using a
strong algorithm.
Review calls to java.security.SecureRandom.getInstance
methods.
Change the algorithm used to ECDRBG or HMACDRBG.
– ECDRBG provides the best long term security.
– HMACDRBG provides better performance than ECDRBG whilst still
providing good security.
11

Upgrading: Sun’s JRE 6.0 to Share for Java
Recommended Code Changes: SSLContext
Issue:
– SecureRandom parameters are sometimes passed to
SSLContext.init. Sometimes this makes sense (for performance
reasons, or because a special HSM SecureRandom object is
being used), but usually, it is better to use the default.
Review calls to the
javax.net.ssl.SSLContext.init(KeyManager[] km,
TrustManager[] tm, SecureRandom random) method.
Passing null for the random parameter to the init method
allows the JSSE provider to choose the best SecureRandom
implementation.
12

Upgrading: Sun’s JRE 6.0 to Share for Java
Recommended Code Changes: SSL Sockets
Issue:
– The TLS protocol version to support can be specified for a socket.
Some applications may use this to limit protocol support to TLSv1,
or maybe SSLv3 and TLSv1. This prevents applications from
connecting with SSLv2. However, this also prevents Share for
Java from using TLSv1.1 and TLSv1.2.
Review calls to
javax.net.ssl.SSLServerSocket.setEnabledProtocols
and javax.net.ssl.SSLSocket.setEnabledProtocols
Either remove these calls or add the values
com.rsa.jsse.JsseProvider.TLS_V11 and
com.rsa.jsse.JsseProvider.TLS_V12 to the array of
algorithms supplied to the setEnabledProtocols method.
13

Upgrading: Sun’s JRE 6.0 to Share for Java
Recommended Code Changes: SSL Sockets
Issue:
– The cipher suites to use can be specified for a socket. Some
applications may use this to limit which cipher suites to use. This
prevents an application from using cipher suites which do not
provide good security. However, this also prevents Share for
Java from using more advanced cipher suites.
Review calls to
javax.net.ssl.SSLServerSocket.setEnabledCipherSuites
and javax.net.ssl.SSLSocket.setEnabledCipherSuites
Either remove these calls or look at the release notes to
determine which cipher suites to add.
14

Upgrading
Share for Java to Crypto-J/Cert-J/SSL-J
15

Upgrading: Share to Crypto-J/Cert-J/SSL-J
Agenda
Agenda
– Introduction
– Class path and provider registration
– FIPS 140
– Native crypto
– PKCS #11
– Feature support:
• Entropy from Hardware Security Module (HSM)
16

Upgrading: Share to Crypto-J/Cert-J/SSL-J
Introduction
sslj.jar
RSA BSAFE ® SSL-J 5.1
RSA BSAFE ® Share
for Java TM Platform
shareTLS.jar
SSLJ API
JSSE API
JSSE API
RSA BSAFE ® Cert-J 3.1
certj.jar
CERTJ API
RSA BSAFE ® Crypto-J 4.1
cryptoj.jar, cryptojFIPS.jar
shareCrypto.jar
JSAFE API
JCE API
JCE API
17

Upgrading: Sun’s JRE 6.0 to Share for Java
Class Path and Provider Registration
shareCrypto.jar and shareTLS.jar must be replaced with
cryptoj.jar or cryptojFIPS.jar, and sslj.jar.
– If shareCrypto.jar and shareTLS.jar are in the jre/lib/ext
directory, they must be removed and replaced with cryptoj.jar or
cryptojFIPS.jar and sslj.jar.
– If shareCrypto.jar and shareTLS.jar are in the class path, they
must be removed and replaced with cryptoj.jar or
cryptojFIPS.jar and sslj.jar.
18

Upgrading: Share to Crypto-J/Cert-J/SSL-J
FIPS 140
For an application to be FIPS 140 compliant, it must:
– Use cryptojFIPS.jar
– Have the com.rsa.cryptoj.kat.strategy property set to
on.load in the jre/lib/security/java.security file.
– Not use non-FIPS 140 algorithms directly or indirectly.
• Cipher Suites: Either don’t set cipher suites explicitly or only use
cipher suites which use only FIPS 140 algorithms.
• Key Stores: Convert PKCS #12 key stores to Crypto-J 4.1 / Share
for Java 1.0 format so that only FIPS 140 algorithms are used.
19

Upgrading: Share to Crypto-J/Cert-J/SSL-J
Native Crypto
To use Native Crypto:
– Ensure the platform specific shared library is in the Java library
path or the system library path.
– On Windows:
• Copy cryptoj\prebuilt\cryptoc\win32\lib\jsafe.dll to
C:\WINDOWS\system32
– Native algorithms will be used if they are available.
20

Upgrading: Share to Crypto-J/Cert-J/SSL-J
PKCS #11
To use PKCS #11 Crypto:
– Ensure the platform specific shared libraries are in the Java library
path or the system library path, and that the PKCS #11 driver is in
the system library path.
– On Windows:
• Copy cryptoj\prebuilt\cryptoc\win32\lib\jsafe.dll
and
cryptoj\prebuilt\cryptoc\win32\lib\jsafepkcs11.dll
to C:\WINDOWS\system32
– Use PKCS #11 algorithms names:
• KeyPairGenerator: DSAWithPKCS11, RSAWithPKCS11.
• Cipher: RSAWithPKCS11.
• Signature: SHA1withRSAandPKCS11, NONEwithRSAandPKCS11,
SHA1withDSAandPKCS11.
21

Upgrading: Share to Crypto-J/Cert-J/SSL-J
Entropy from a Hardware Security Module
Entropy can be supplied to Crypto-J from an external
source, such as an HSM:
– Ensure the HSM specific JCE provider is available.
– Use com.rsa.jsafe.crypto.CryptoJ’s
setSeeder(SecureRandom, boolean) method.
– See the javadoc for more details.
22

Thank you!