I’ve written about several SecureRandom implementations in the past. While analyzing the default SecureRandom implementation in IBM JCE (v1.7) on *nix, I came across several weaknesses. IBM recently released a patch to fix the issues. Let’s take a look at how this SecureRandom implementation works as well as the issues that were recently patched.
Note that the description below is for the unpatched version of IBMSecureRandom. I have not analyzed the latest version that fixes the issues.
On *nix installations of the IBM JRE, IBMJCE is the only default crypto provider that includes SecureRandom implementations. The default SecureRandom implementation in the IBMJCE is IBMSecureRandom. If it happens to not be the default, the implementation can be instantiated using:
This implementation of SecureRandom can be seeded using two different mechanisms as discussed below:
The output of the IBMSecureRandom PRNG is generated using applications of the MD5 hash function. Although MD5 is not considered a secure hash function anymore since it is not collision resistant, use of MD5 here is probably okay because pre-image resistance has not yet been broken in MD5.
However, the way in which MD5 is used here is insecure. The PRNG essentially outputs 8 bytes of its internal state and then hashes the entire internal state using MD5. Therefore, an attacker who can see the PRNG’s output sees half of the PRNG’s internal state. For example, I observed the following output generated by the given state:
An attacker that sees the PRNG’s output would only need to brute force 64 bits of the internal state to predict all future outputs of the PRNG.
Another potential problem with using MD5 here is that the internal state of the PRNG is only 128 bits, which is not acceptable for many scenarios. For example, if you were to shuffle a deck of cards using this PRNG, you would only get 2128 possible card shuffles. However, there are actually 52! – or approximately 2226 possible card shuffles. Many PRNGs aren’t acceptable for shuffling decks of cards for this reason; however, a 128-bit PRNG state is not acceptable for a lot of applications.
If generateSeed() is called, the resulting seed is generated using operations performed on the output of java.util.Random seeded with the system time. Therefore, these seeds are potentially predictable.
Here’s a summary of the main security issues that I discovered:
If your application relies on the unpredictability of outputs from an unpatched version of this implementation (e.g. if you use it to generate session identifiers, passwords, cryptographic keys, etc.), then you have a problem.
Note that some other JCE providers also use IBMSecureRandom for various purposes. So, the issues in the unpatched IBMSecureRandom may impact other JCE providers as well. If you have the IBMJCE provider enabled in your application (even if you’re not using IBMSecureRandom explicitly), make sure that you apply the latest patch from IBM as soon as possible.
What are the lessons learned here? Secure pseudo-random number generation is hard. Even widely used pseudo-random number generators from reputable vendors can contain security issues. If you rolled your own pseudo-random number generator without help from cryptography experts, assume that it’s insecure. If you are using a pseudo-random number generator provided by an OS vendor or a crypto library, don’t just assume that it’s secure. Ask the vendor if the implementation has been reviewed by a third party. Ensure that any third-party reviews didn’t just involve performing statistical analysis on the outputs of the PRNG. The actual implementation details need to be analyzed.
+Amit Sethi is a Technical Manager at Cigital. His software security expertise includes architectural risk analysis, threat modeling, secure code reviews, penetration testing, and more. He has helped many multi-national corporations solve complex security problems and is a contributor to The Justice League Blog.
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 Game-Changing Red Team
The Secret to Red Teaming: Thinking Maliciously
Content Security Policy Reporting
Analyst Reports, Where is Cigital?
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
.@CigitalGEM weighs in on "Crypto Wars II" with @SteveBellovin & @matthew_d_green sws.ec/1I4HytA pic.twitter.com/TL0xBMp3FS
Yesterday at 10:32 am
The secret to Red Teaming is putting yourself in the attacker's perspective sws.ec/1KtvTHP #appsec pic.twitter.com/PcivNyq2oQ
Yesterday at 9:37 am