Live data from Hacker News

Android RNG Weakness Renders Bitcoin Wallets Insecure

bitcoin.org

21–30 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#21
post #6

Iä! Digital Signature Algorithm! The Black Goat of the Woods with a Thousand Crypto Bugs! I don't know the Bitcoin software involved at all, but I can sketch out an attack that might shed some light on it, and, more importantly, instill an appropriate fear of DSA into you: To generate a DSA key, you come up with primes p and q and a generator g, which process is a paralytic non-Euclidian brain injury I will not attem…

Lest we think everything's lost, Thomas Pornin's RFC to fix (EC)DSA's need for good randomness when signing was published this month [1]. The approach is similar to Dan Bernstein et al's EdDSA.

[1] http://tools.ietf.org/html/rfc6979

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#22
post #10

Earlier quoted context omitted.

People are saying it's a problem with Android's SecureRandom implementation. That would be a pretty big problem if it returns repeated random numbers. But it seems strange that such a large obvious problem would make it into Android. The other explanation is that Android bitcoin developers are all implementing it incorrectly and either don't realize it or are trying to push the blame somewhere else.

This is the most likely scenario. While I don't know Java technically, .NET has a similar "vulnerability" if you use more than one RNG. It uses time to seed new values and the general rule is you use this as a singleton/static app-wide. If you don't do this, all your rng's share the exact same value. It's really awkward to stumble into as all the evidence points to the framework but when you rtfm you realize no, its…

A secure random number generator wouldn't seed based on time in the first place, though.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#23
post #16
post #14

Earlier quoted context omitted.

As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.

If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?

Well there is this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-Stat...

Quote:

> Apache Harmony revealed multiple weaknesses caused by implementation bugs. As a part of Android a plethora of cryptographic functions [17] rely on this PRNG. One of the bugs addresses directly the Android platform, where as the second one only targets Apache Harmony.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#24
post #11
post #2

discussion on bitcointalk.org: https://bitcointalk.org/index.php?topic=271486.0 blogpost about weakness in java.security.SecureRandom: http://armoredbarista.blogspot.com.au/2013/03/randomly-faile...

That second link doesn't seem to be the current problem. The current problem is that the same random number is being returned more than once.

On the other hand, the author of the Bitcoin Wallet Android app thinks it's a SecureRandom problem: https://code.google.com/p/bitcoin-wallet/source/detail?name=...

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#25
Seems that some invocations of SecureRandom were able to always get the same result.

http://blog.kchandrahasa.com/blog/2013/08/09/android-4-dot-2...

However I've read somewhere that now apparently even Android 4.2 is affected which would mean there's something more? Whoever knows more, please write more technical details.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#26
post #9
post #4

Does it concerns only Bitcoin wallets? What about other encryption under Android - like files, etc?

This is a Bitcoin software implementation bug, and an illustration of why you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG.

you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG

Bad advice. Use your OS's CSPRNG to get a seed, but work with your own PRNG (say, HMAC_DRBG) internally. Going to the OS every time you want a few bits is both very slow and makes it far easier for local attackers to see when you're using entropy.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#27
post #16
post #14

Earlier quoted context omitted.

As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.

If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?

I have done a bit of source diving in response to your question, and the answer is that all I can provide is the bitcoiners' announcement:

https://bitcointalk.org/index.php?topic=271831.0

They claim the problem lies with 'a component of Android'. One of them told me that the solution was to switch from using SecureRandom to reading /dev/urandom directly. The actual source changes appear not to be public, and he wouldn't tell me details about the issue.

I tried to find the usages of SecureRandom in a couple of the apps that are supposed to be affected, but a cursory search didn't turn up much. I suspect it's inside some library that I don't know to look inside. The question, I guess, is whether all the affected apps share the same library or not -- I don't _think_ so, but if they do it would dramatically reduce my confidence that the issue lies with the Android platform, as claimed.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#28
post #23
post #16

Earlier quoted context omitted.

If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?

Well there is this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-Stat... Quote: > Apache Harmony revealed multiple weaknesses caused by implementation bugs. As a part of Android a plethora of cryptographic functions [17] rely on this PRNG. One of the bugs addresses directly the Android platform, where as the second one only targets Apache Harmony.

The bug described here isn't sufficient to generate repeated DSA k-values, even if it is still in the code†, which is unlikely. It seems more likely that the application code used SecureRandom insecurely, as described upthread.

It's virtually certain not to be in the code, since Android's CSPRNG is based on OpenSSL now, not Harmony's built-in CSPRNG.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#29
post #19
post #18

Earlier quoted context omitted.

As tptacek has mentioned many, many times, SecureRandom is one of those things which is very secure if you understand exactly what it is doing and do not shoot yourself in the foot. One easy way to shoot yourself in the foot with SecureRandom is to use seed values from a source with low entropy. http://developer.android.com/reference/java/security/SecureR... If one were to copy/paste the sort of code samples which sh…

They were explicitly seeding SecureRandom?

Don't know. This just seemed like the high-percentage guess.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#30
post #16
post #14

Earlier quoted context omitted.

As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.

If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?

Actually, someone elsewhere in the thread has found, and linked, the bugfix commit, in another Android bitcoin wallet:

https://code.google.com/p/bitcoin-wallet/source/detail?name=...

So literally they're just ripping out SecureRandom and replacing it with their own stub that reads /dev/urandom.

Post reply on HN