Google Admits Bitcoin Thieves Exploited Android Crypto PRNG Flaw

rjmarvin writes "The theft of 55 Bitcoins, or about $5,720, through Android wallet apps last week was made possible because of flaws in Android's Java and OpenSSL crypto PRNG, Google revealed in a blog post. In the wake of a Bitcoin security advisory and a Symantec vulnerability report, the Android Developers Blog admitted the reason the thieves were able to pilfer their wallet apps. The flaws are already, or in the process of being repaired."

Comments

Re:How does this get fixed?

[Baloroth]

The flaw can be fixed at the application level by manually initializing the PRNG with entropy from /dev/random or /dev/urandom (the built-in tool wasn't doing that properly unless explicitly told to, hence the vulnerability). Some apps will already be immune, and the rest can be patched to fix the problem. An update to Android proper is not required, unless the app isn't updated for some reason (in which case, find a new wallet).

Re:Still only one of 360,000 apps

[GoogleShill]

It isn't programmer negligence in this case, it's the underlying Android implementation. The default constructor is supposed to seed the generator with secure entropy. Conversely, setSeed() is considered insecure and not recommended.

See SecureRandom

Re:How does this get fixed?

[Tailhook]

Why wouldn't you just use /dev/urandom (or better, /dev/random) instead? More layers for more chances to fuck it up?

This is ignorant and needs to be called out.

/dev/(u)random draw on a finite entropy pool. The pool is easily depleted. When there is too little entropy /dev/random blocks on read(2), ruining performance, and /dev/urandom output is cryptographically compromised. From random(4):

The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of data from this device will have a negative impact on other users of the device.

Initializing a CSPRNG such as SecureRandom is exactly the intended purpose of /dev/(u)random.

Cryptography does not belong in the hands of second string hacks like the parent AC. It is possible that /dev/(u)random is a bit too easily abused by fools.