As we previously mentioned, there have been problems with Bitcoin wallets on Android due to implementation problems with SecureRandom on Android not having enough entropy to be cryptographically useful and this has lead to Bitcoin theft. But, the problem has got worse. It was assumed by many, us included, that this was traceable to Android’s use of the broken Apache Harmony code for Secure Random.
Now though, a posting on the Android Developers blog lightly titled “Some SecureRandom Thoughts” shows that Google did pick up on the problem with the Apache Harmony code and replaced it in 4.2 with an implementation that used the system-level OpenSSL PRNG (Pseudo Random Number Generator). The only problem is that the OpenSSL PRNG wasn’t being properly initialised so was more predictable. And its not like the problem was unknown; HttpClient and java.net classes also use the OpenSSL PRNG and made sure it was seeded with values from /dev/urandom.
The posting includes an all-versions SecureRandom patch which developers can include in their code, which not only replaces the Harmony derived code on older versions but also correctly seeds the OpenSSL PRNG. Google are suggesting that anyone who uses the Java Crypto API for key or random number generation or signing update their code and “evaluate whether to regenerate” previously generated keys.
There are patches available which have been provided to Open Handset Alliance partners, so with any luck we’ll see those widely deployed by the end of the … well at some point in time at least. OHA partners time to ship patches is a PRNG all of its own.
Apparently, at least according to the code, all these bugs have been fixed in Android 4.3. That was released on July 24 before the BitCoin thefts started. Did the 4.3 changes give an attacker a clue to vulnerabilities?
Edit: Misread the code. The bugs are in 4.3 too and the patching applies to that too.
Unfortunately, Google’s ostensible public handling of the problem as a bug rather than a security vulnerability probably means we’ll never know the full story behind this problem and why Google, when changing PRNG, didn’t extensively test the consumers of that PRNG.
This article was imported from the original CodeScaling blog