Java Crypto weakness could affect security in hundreds of thousands of apps.

Google developers have confirmed a cryptographic vulnerability in the Android operating system that researchers say could generate serious security glitches on hundreds of thousands of end-user apps, many of them used to make Bitcoin transactions.

This weakness in Android's Java Cryptography Architecture is the root cause of a Bitcoin transaction that reportedly was exploited to pilfer about $5,720 worth of bitcoins out of a digital wallet last week. The disclosure, included in a blog post published Wednesday by Google security engineer Alex Klyubin, was the first official confirmation of the Android vulnerability since Ars and others reported the incident last weekend. Klyubin warned that other apps might also be compromised unless developers change the way they access so-called PRNGs, short for pseudo random number generators.

"We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG," he wrote. "Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected." Apps that establish encrypted connections using the HttpClient and java.net classes aren't vulnerable.

The confirmation came a few hours after researchers from security firm Symantec warned that hundreds of thousands of Android apps may be affected by the vulnerability. By Symantec's count, as many as 360,000 programs rely on the SecureRandom, which is one of the programming services for generating random numbers provided by the JCA. Contrary to many earlier reports, the flaw affects all versions of Android, not just 4.2 and earlier, Android Security Engineer Adrian Ludwig told Ars.

"Call me the tumblin' dice"

PRNGs ensure that computers produce long numbers that are impossible to predict ahead of time and are a core requirement in many cryptographic applications. They're akin to the shakers used by board game players to make sure dice don't land in predictable patterns. Among other things, the random numbers PRNGs produce help ensure that the secret keys used to encrypt or digitally sign data can't be cracked easily.

The Android apps that were exploited in the recent Bitcoin thefts may have signed multiple transactions using an identical number the apps presumed was random, Symantec researchers said in their blog post. "Since transactions are public on the Bitcoin network, attackers scanned the transaction block chain looking for these particular transactions to retrieve the private key and transfer funds from the Bitcoin wallet without the owner’s consent."

Wednesday's blog post from Google recommended developers update all apps that use JCA to "explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random." The advisory went on to suggest developers consider regenerating cryptographic keys or other random values that were previously generated using JCA programming interfaces including SecureRandom, KeyGenerator, KeyPairGenerator, KeyAgreement, and Signature. It also provided example code for implementing the suggestions.

The post said Google developers have delivered patches to handset manufacturers but gave no indication when those updates may find their way onto end-user devices. Instead, the post emphasized the steps third-party developers should take to ensure their Android software. At least four Bitcoin wallets have already been updated to close the vulnerability, according to a Bitcoin advisory that was updated Tuesday. It wouldn't be surprising to see many more apps follow suit in the next few days.

Promoted Comments

Having ported or implemented various crypto code on embedded platforms, I find random number generation to be the most complicated part of the work.

Based on that experience (and seeing a lot of PRNG related vulnerabilities in the recent past) I believe that CSRNG/PRNG algorithms must be the first thing to audit on systems where security is required.

In his Coursera Cryptography course Dan Boneh covers the fact that rand() is not suitable for use as a PRG in crypto. I am wondering how /dev/random relates, and if it isnt suitable as a secure PRG then how on earth does this mistake slip by Oracle/Google dev and QA? Scary indeed.

I wouldn't worry so much as to the source of the original randomness, more important how come the battery of known statistical tests were not run in the first place? As the saying goes, you get what you pay for and when it comes to open source, it's often testing and validation that's missing. The only reason we know about it today is because someone did run the tests years later.

Yeah that's what surprises me too here. How the hell could google *not* run at least some chi-square test for their random generator? That's just astonishingly unprofessional.

I wouldn't worry so much as to the source of the original randomness, more important how come the battery of known statistical tests were not run in the first place?

The known statistical tests are useless for detecting badly-seeded generators - the output stream from a badly-seeded generator is beautifully random, it's just that it's quite likely to be identical to the output stream from a different instantiation of the badly-seeded generator.

"Start up a new freshly-installed VM, immediately generate a keypair, repeat process a million times, check that no key pairs match" is a CPU-year or so of work and only gives you decent confidence that there are at least 35 bits of entropy in the seeding of the generator. Even worse is if your hardware isn't nicely virtualisable and you have to factory-reset a physical box per key generation test.

I wouldn't worry so much as to the source of the original randomness, more important how come the battery of known statistical tests were not run in the first place?

The known statistical tests are useless for detecting badly-seeded generators - the output stream from a badly-seeded generator is beautifully random, it's just that it's quite likely to be identical to the output stream from a different instantiation of the badly-seeded generator..

That's wrong and Knuth has a whole chapter in TAoCP about these kind of tests.

So Google can make a Web Browser that is hacker proof for 3+ years running. Translate that over to a Browser-based OS. But they manage a full blown exploit on their other OS ? Someone seems to have dropped the ball here.