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.
Software Developers vs. Software Security: Why Can’t We All Get Along?
Gary McGraw discusses the security risks of dynamic code
The Cathedral and the Bazaar of Software Security Vulnerabilities
Serving Resources Over SSL With CSP Upgrade-Insecure-Requests
RT @cigitaljobs: .@cigitaljobs will soon combine with @cigital! Follow @Cigital to stay current on our #appsec opportunities! pic.twitter.com/au4vYsJnnW
About 4 hours ago
RT @RSAConference: The top 10 online #safety tips. Share these with your family! #RSACCyberSafety: spr.ly/6016By8Jo
About 7 hours ago
"What’s the cause of the developer/security divide?" @cketkar | sws.ec/1Xg2uI9
RT @CIOonline: Study: 81% of large healthcare organizations breached trib.al/0LNe6I8 @CIOonline #healthcare #breaches
Researchers discover new keychain vulnerability in OSX via @CSOonline | sws.ec/1EyGeTM pic.twitter.com/5XMomoes8b
About 8 hours ago