My previous blog entry on SecureRandom was Issues to be aware of when using Java’s SecureRandom. Today, I’ll write about the most complex SecureRandom implementation I’ve seen so far.
This implementation is the default SecureRandom implementation in Oracle JRE installations on Windows. If it is configured to not be the default, it can be instantiated using:
This implementation of SecureRandom can be seeded using two mechanisms (when default configurations are used – non-default configurations will be discussed later):
The output of the SHA1PRNG is generated using applications of the SHA-1 hash function.
If generateSeed() is called, the Windows CryptGenRandom() function is used to generate a seed on Windows, and /dev/random is used to generate a seed on *nix by default. Since reads from /dev/random can block if insufficient entropy is available, the seed generation operation on *nix could hang.
Note that unlike what the Javadocs at http://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html#generateSeed(int) state, the mechanism used to generate this seed is not the same as the mechanism used to seed SecureRandom instances as described in an earlier section. It is similar to the way in which the static SecureRandom instance is seeded; however, SeedGenerator.getSystemEntropy() is not used here.
The sun.security.provider.SecureRandom implementation contains a static SecureRandom instance that is used to seed SHA1PRNG instances generated for callers. The static instance is seeded using sun.security.provider.SeedGenerator. Depending on the Java Virtual Machine’s configuration, the actual seeding mechanism may vary. The various mechanisms are described in the subsections below.
Regardless of the configuration, the SeedGenerator.getSystemEntropy() method is always used as part of the seed. This method outputs a SHA-1 hash of the following:
The following values are used to determine where the rest of the seed entropy is obtained:
The java.security.egd system property takes precedence. By default, java.security.egd is not defined, and securerandom.source is set to file:/dev/urandom. The value set by these properties will be referred to as egdSource below. The seeding mechanisms are chosen as follows:
The *nix implementation uses sun.security.provider.SeedGenerator.URLSeedGenerator with /dev/random. This results in the seed being read from /dev/random. Note that since reads from /dev/random can block if insufficient entropy is available, the seed generation operation on *nix could hang.
The Windows implementation uses the Windows CryptGenRandom() function to generate the seed.
This implementation reads from the given URL (which could be a local file) and returns the first bytes at the URL as the seed.
This implementation spawns a thread that runs for approximately 250ms, and counts the number of times a loop executes while the thread is running. This results in one byte of unpredictable output being generated. This seed generator is quite slow and generates at most 4 bytes per second. Seeding a SHA1PRNG instance using this mechanism takes at least 5 seconds.
The sun.security.provider.SecureRandom implementation is the most complex SecureRandom implementation I’ve seen so far in terms of the number of ways in which it can be configured and used. In general, it works as expected, but there are a few configuration and usage issues to be aware of:
Amit Sethi, Principal Consultant, has been with Cigital since 2004. He specializes in Mobile Security, Online Game Security and Cryptography. Amit’s work includes extracting cryptographic keys from embedded devices using side-channel attacks, designing mechanisms to make those attacks more difficult, and designing a format-preserving encryption algorithm based on well-studied cryptographic primitives for a Fortune 500 company. Even in his free time, Amit enjoys reverse engineering binaries, analyzing open source software, and experimenting with new technologies.
Words of Security Wisdom: Just because you don’t know of any security incidents in your software/environment doesn’t mean that you haven’t had any security incidents –especially if you don’t have good monitoring controls in place.
Cigital is one of the world’s largest application security firms. We go beyond traditional testing services to help our clients find, fix and prevent vulnerabilities in the applications that power their business.
Our experts also provide remediation guidance, program design services, and training that empower you to build and maintain secure applications.
Building Security into the SDLC Without Impacting Velocity
Adding Security Steps to Your “agile” Development Process
Benefits of Code Scanning for Code Review
Developers Targeted in Apple’s iOS Malware Attack
Learn to Minimize Time and Resources spent on Application Security Testing in this Whitepaper | sws.ec/1LdYHWK #appsec
About an hour ago
#InfoSeCon is coming October 8th and we have a discount code "CIGITALGUEST2015" for 30% Off tickets! sws.ec/1WvsuOk
.@cigitalgem : Seven myths of software security best practices via @TechTarget | sws.ec/1jK5NrN #appsec
About 3 hours ago
Don't wait until you compile code to test it, do it in the IDE with SecureAssist. sws.ec/1KRL1w7
October 4, 2015 11:04 am
Get a free 30-day trial of SecureAssist & build more secure code from the start. Click here sws.ec/1KRKVVg pic.twitter.com/D5gTJjoF9K
October 3, 2015 11:15 am