IBM SecureRandom Provider

IBM® SecureRandom provides cryptographically strong random number generation as an alternative to the IBM JCE SecureRandom provider.

The provider contains implementations of MD5, SHA1, IBMSecureRandom, and SHA1PRNG. The algorithms MD5 and SHA1 are present only to supplement the SecureRandom implementations. The provider does not expose these algorithms as Message Digests that the provider supports.

The algorithms provided include:
Random number generation algorithms

IBMSecureRandom: The name of the pseudo-random number generation (PRNG) algorithm supplied by the IBMSecureRandom provider. This implementation uses a SHA-1 message digest and computes the hash over a true-random seed value.

SHA1PRNG: The name of the pseudo-random number generation (PRNG) algorithm supplied by the IBMSecureRandom provider. This implementation uses a SHA-1 message digest and computes the hash over a true-random seed value. Start of changes for service refresh 1 fix pack 10The implementation supports a customizable source for seed data. By default, an attempt is made to use the entropy gathering device specified by the securerandom.source security property in the java.security file. The entropy gathering device can also be specified with the system property java.security.egd. Specifying this system property overrides the securerandom.source security property. On Windows systems, specifying a URL of file:/dev/random or file:/dev/urandom for the seed source enables the native Microsoft CryptoAPI seeding mechanism. If an exception occurs while accessing the specified seed source, a traditional system or thread activity algorithm is used.End of changes for service refresh 1 fix pack 10

Differences between IBM SecureRandom and IBM JCE SecureRandom

The IBM SecureRandom algorithm in the IBM SecureRandom provider does not meet all of the government security specifications that are required for IBM JCE SecureRandom. As a consequence, the performance is improved. However, you must use the IBM SecureRandom provider only for operations that do not need to meet the strict JCE specification.

The IBM SecureRandom provider is intended only as a replacement for the SecureRandom algorithms of the IBMJCE provider. You must not use the IBM SecureRandom provider to replace the SecureRandom algorithms in any other provider, including IBMJCEFIPS.

How to implement the IBM SecureRandom provider

The IBMSecureRandom.jar file containing the provider can be found in the jre/lib/endorsed directory (HP-UX and Solaris operating systems) or the jre/lib/ext directory (other operating systems). The IBM SecureRandom provider is not in the provider list by default. If you want to use this provider, follow these steps:
  1. Edit the following file: jre/lib/security/java.security.
  2. Insert the IBM SecureRandom provider into the list before the IBM JCE provider. For example:
    ....
    security.provider.2=com.ibm.securerandom.provider.IBMSecureRandom
    security.provider.3=com.ibm.crypto.provider.IBMJCE
    ....
  3. Save the file.

How to access the provider

The following extract shows you how to access the provider in your code:
        SecureRandom random=null;
        SecureRandom random1=null;
        
      try {
          random = SecureRandom.getInstance
("IBMSecureRandom","IBMSecureRandom");
          random1 = SecureRandom.getInstance("SHA1PRNG","IBMSecureRandom");

      } catch (NoSuchAlgorithmException nsae ) {
          System.out.println("No such alg : "+nsae);
          System.exit(-1);
      } catch (NoSuchProviderException nspe ) {

          System.out.println("No such provider : " + nspe);
          System.exit(-1);
      }
Start of changes for service refresh 1 fix pack 10

Considerations for z/OS

Changes are included in the SecureRandom class to improve randomness, which is critical to the security of private keys and stronger cryptographic operations. On z/OS, random data is acquired from /dev/random and /dev/urandom. The use of /dev/random and /dev/urandom places a dependency on ICSF for generating the random data. As a consequence, the RACF CSFSERV Access Permission for CSFRNG (random number generate callable service) must be granted to the exploiter to permit execution of those ICSF services that provide the requested cryptographic support for random number generation.

End of changes for service refresh 1 fix pack 10