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.
How to Build a Red Teaming Playbook
How to Build a Game-Changing Red Team
The Secret to Red Teaming: Thinking Maliciously
Content Security Policy Reporting
#BHUSA is almost here and we want to see you there, come see the @Cigital team at Booth 1131 and lets talk security! #appsec
15 minutes ago
Why Managed Application Security Services? | sws.ec/1MweFgb
About an hour ago
It Only Takes One Text To Hack 950 Million Android Phones via @ForbesTech sws.ec/1U2ltn7 pic.twitter.com/BWR75m6jHY
Yesterday at 12:23 pm
Come visit us at #BHUSA next week at Booth 1131 and ask us for one of these, we'll be there all week! pic.twitter.com/SR0QTtMTBX
Yesterday at 11:44 am
Our @pacohope give his opinion on Remote Car Hacking in @SecurityWeek's latest Feedback Friday sws.ec/1CVjCMJ
Yesterday at 11:19 am