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

How does this get fixed?

[mveloso]

Is it up to the OEM to backport the patch to all the various android versions that they have? If so, this vulnerability will live forever.

It's like google and its partners are building this huge botnet of vulnerable devices. Every year it gets bigger.

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: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.

Too many insecure systems ...

[gstoddart]

This is why I wouldn't ever consider having my cell phone be something which can directly access my money.

I don't trust the makers to competently build in security, and I believe that once everyone knows your cell phone is likely to be tied to your bank account, it's a soft target.

They keep trying to find new ways to make it more 'convenient' to use these things to spend money, but 'convenient' in this case means insecure and fraught with privacy issues (and extra service fees if they can get away with it).

Same with that tap to pay mechanism ... wow, you mean anybody with my physical card can spend my money without authorization? Gee, sign me up for that.

Tech companies want to make a product or app for pretty much everything -- and a lot of them I find myself asking "who would want that?".

Now, mind the steps while you're leaving my lawn, and don't trip on the sprinkler.

Re:Already or in the process of being repaired

[gstoddart]

This is what you get for playing with bit coin. When are you going to learn?

You know, it's not even bitcoin.

Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected

The entire crypto on the platform is vulnerable from the looks of it.

So, I would assume if there were other digital wallet type things on Android, they would be subject to the exact same vulnerability.

Bring in the regulators!

[meta-monkey]

I'm so glad they're going to start regulating bitcoin. I mean, somebody ran off with $5,720! Monstrous!

That's why I keep my money in safe, secure U.S. dollars and in the stock market, where you don't have to worry about dangerous criminals absconding with your savings.

Why is the industry still using pseudo-randoms?

[MrKevvy]

True random numbers are as simple as a reversed Zener diode connected to an A/D converter... quantum tunneling across the diode creates truly random signal, equivalent to thermal noise.

So why isn't every CPU nowadays equipped with this, so that the RND function is done in hardware?

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

Amateurs. OpenSSL is _not_ the problem.

[gweihir]

This is not an OpenSSL-flaw. Proper initialization of a CPRNG is critical and the OpenSSL documentation states that. The choice of OpenSSL is however especially bad with a bad initialization, as the OpenSSL CPRNG does not continue to seed the generator with additional entropy during its operation, unlike /dev/random or /dev/urandom. Google messed up spectacularly in two regards:

1. They had nobody that understood secure random number generation on the team
2. They did not have their solution independently reviewed by a competent 3rd party

They also selected a CPRNG especially vulnerable to bad seeding and did not use a source of good seeding readily available.

These mistakes are on low amateur level when implementing cryptographic functionality. The dangers of bad CPRNG seeding have been well understood for decades. This looks like the all-to-often found mixture of incompetence and arrogance.