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

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

Re:Already or in the process of being repaired

[Bam_Thwok]

I assure you, he was casting aspersions on all digital wallet type things, not just bitcoin. Bitcoin advocates love to tout how awesomely anonymous and secure and perfect and futuristic it is. Then scams and simple robberies like this happen all the time, and normal people say "caveat emptor, you fool" while the mouthbreathers insist that "It's not a problem with BITCOIN per se! Bitcoin is still great! Bittcoin 4eva!"

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.