Bitcoin thieves expose Android flaw to steal currency

Fans of the fledgling cryptocurrency known as Bitcoin got quite a shock in recent days as some clever thieves worked out yet another method to swipe virtual cash from unsuspecting users. The source of the theft was traced to a bug in Android, and now Google has acknowledged the flaw exists.

Another day, another Android flaw.

  • Odi Kosmatos

    Bitcoin is showing up all over the place these days. This is a game changer and I can’t help but feel it will wrestle some control from the world’s governments hands and back to the people.

  • TechManMike

    What’s even funnier is that when you read the comments on the article, you can tell they’re made by Android fans because all they try to do is discredit Bitcoin as a business. Never mind the fact that the article is about an Android flaw.

  • It isn’t incorrect to say it is an Android flaw since it uses this code but the problem is with the Java Cryptography Architecture library, not Android code specifically. This goes way beyond Android to any Java system (ColdFusion webserver, grails, etc).

    Here’s Google’s explanation of the issue and a glob of code to resolve it:

    • David Kolb

      Actually, no. The is the way Android implements JCA combined with how they create new processes for an opening application. The bug actually is a breech of the JCA contract in that creating a new SecureRandom object is supposed to create a new PRANG with it’s own state and freshly seeded from the entropy pool.

      Instead, all applications inherit the same PRANG from the zygote process they are forked from. Furthermore, applications that follow due diligence and occasionally create a new SecureRandom object are surprised by the JVM handing them back the exact same object they had before.

      This is because JCA on Android is backed by OpenSSL’s PRANG, which is fast and written in C, but global to OpenSSL. Furthermore, Android’s JCA fails to re-seed upon initialization of a new SecureRandom object, something that would’ve at least somewhat mitigated the issue, but not completely.

      So the end result was every application ends up with the exact same initial PRANG state, meaning you can reasonably guess what random numbers everyone else on a particular phone is generating.

      This issue does not exist on Oracle Java implementations since every process gets a different SecureRandom object backed by a different PRANG state.

      • Correct. I believe you misunderstood. My comment was not about other systems presently being affected just that the implementation, as showcased by Android, is the problem.