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.
- 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. The 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.
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
- Edit the following file: jre/lib/security/java.security.
- 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 ....
- Save the file.
How to access the provider
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);
}
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.