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?

[gstoddart]

MetroPCS will happily sell you a BRAND-NEW Android 2.3 device right now.

Which to me pokes holes in the theory this is up to the consumer to be responsible for.

The vast majority of people looking to buy a smart phone won't likely know much about what versions of the OS the phone is running.

It's like selling a product you know might catch fire and kill someone -- you can't just say it's up to the consumer to not buy that model.

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.

Still only one of 360,000 apps

[sl4shd0rk]

FTFA: security researchers from Symantec issued a report on upwards of 360,000 apps using the SecureRandom class, containing the PRNG flaw in Bitcoinâ(TM)s Elliptic Curve Digital Signature Algorithm (ECDSA).

May give a potential indication at the sheer number of applications affected by this exploit (which is programmer negligence apparently). Drilling into the Symantec article reveals how they arrived at that number.

we have found over 360,000 applications that make use of SecureRandom and over 320,000 of them use SecureRandom in the same way the bitcoin wallets did (they did not call setSeed).

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: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:Why is the industry still using pseudo-randoms?

[gweihir]

You ask the wrong question. Many embedded CPUs have these devices and with a driver, the Linux kernel uses them. But when the application designers chose to ignore /dev/random (where the kernel exposes its entropy collection), then no amount of good randomness provided by the kernel will help. Incidentally, /dev/random is very good even without hardware RNG, in certain situations you may just have to wait a bit.

The second problem here was that the OpenSSL CPRNG is by its design very much dependent on a good initialization. This is not an obscure or hidden fact, but apparently Google had no competent security people on this project and did not ask any competent 3rd party for an independent review.

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.

Re:Someone is gonna say, "I told you so..."

[petermgreen]

One big security problem with andriod is the distribution model. Google makes andriod and distributes it to their OEM partners (and to the general public though sometimes with a delay). The OEMs then customise it and pass it on to their users and in most cases (nexus excepted) all updates go through the OEM.

The result is you get the situation of there being lots of older smartphones out there that are still perfectly usable but are no longer able to receive security updates in the regular manner because the OEM can no longer be bothered updating them. Sometimes it's possible to unlock the bootloader and install an unofficial build but that is at best something that requires you to be fairly technical and at worst something where even a computer expert like me can find myself in a dead end*.

* For example htc officially offers a bootloader unlock process but when I tried it on my brother's old wildfire the software version on it was too new to apply the RUU needed for the bootloader unlock process.