Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android RNG Weakness Renders Bitcoin Wallets Insecure

bitcoin.org

Post reply on HN
Print view View original

31–40 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#31

Post by glurgh »

tptacek wrote: post #19
patio11 wrote: 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?

Not in the bitcoinj library they all appear to be using, no. That, in turn, uses bouncycastle. Bitcoinj is not explicitly seeding SecureRandom, I'm reasonably sure.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#32

Post by glurgh »

gwillen wrote: post #27
tptacek wrote: 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?

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 would…

That's the lib, if you're bored enough to keep diving

https://code.google.com/p/bitcoinj/

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#33

Post by filipmaertens »

At blog post https://cryptocow.com/?p=201 we've been experimenting with using sensors to upgrade PRNG's, and we frankly can't understand why this isn't been used natively in Android RNG implementations... It's trivial, easy and tremendously increases the RNG quality.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#34

Post by [deleted] »

tptacek wrote: post #16
gwillen wrote: 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?

[deleted]

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#35

Post by kllrnohj »

Android's SecureRandom uses BouncyCastle prior to 4.2 and OpenSSL in 4.2+ ( http://android-developers.blogspot.com.au/2013/02/security-e... )

It'd be interesting to know what the bug is and if that bug affects Bouncy Castle and/or OpenSSL as well, or if Google screwed up the glue code somehow

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#36

Post by gwillen »

glurgh wrote: post #32
gwillen wrote: post #27

Earlier quoted context omitted.

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 would…

That's the lib, if you're bored enough to keep diving https://code.google.com/p/bitcoinj/

OK, I dove a little more. The actual signing happens in org.spongycastle.crypto.signers.ECDSASigner . I haven't dug into _that_ yet.

But one thing I'm wondering is: would any setSeed on any SecureRandom instance cause a potential problem? Or just on the same instance being used for signing? In other words, do I only need to check that spongycastle -- which I presume is a fork of bouncycastle -- handles things reasonably? Or could any other messing about with SecureRandom mess it up?

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#37

Post by tptacek »

cperciva wrote: post #26
tptacek wrote: post #9

Earlier quoted context omitted.

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.

Strongest possible disagree. For instance, the Debian OpenSSL bug was an entirely unforced error stemming from applications that chose to use Debian OpenSSL's terrible CSPRNG on top of the OS's CSPRNG. The local attacker scenario you're talking about is a theoretical risk when there are attackers running code in the same OS as your CSPRNG; a far more likely concrete flaw is, for instance, a SecureRandom implementation that allows developers to specify insecure seed values.

I'll go to bat on this disagreement. Don't use application-layer CSPRNGs. Use the one the OS provides, to the exclusion of alternatives.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#38

Post by tptacek »

glurgh wrote: post #31
tptacek wrote: post #19

Earlier quoted context omitted.

They were explicitly seeding SecureRandom?

Not in the bitcoinj library they all appear to be using, no. That, in turn, uses bouncycastle. Bitcoinj is not explicitly seeding SecureRandom, I'm reasonably sure.

I couldn't find a line of code in bitcoinj that explicitly seeded SecureRandom, or used the explicit-seed constructor.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#39

Post by tjohns »

acqq wrote: post #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.

To be specific, since I spent a lot of time on that bug...

Older versions of Android's SecureRandom could return the same value if (a) you were manually seeding SecureRandom and (b) no prior crypto operations were performed on that SecureRandom instance before seeding,

There was some (very) bad advice circulating on blogs which advised using this technique to generate local encryption keys from a seed, in order to obfuscate the key.

This was fixed in Android 4.2 when we switched from BouncyCastle to OpenSSL as the underlying crypto provider. I don't know why you'd still be seeing this on Android 4.2, but you shouldn't be doing this anyway. SecureRandom is seeded by the system. Manually seeding it is a bad idea. (And trying to force deterministic output from is a very bad idea.)

There's a blog post I wrote which goes into a bit more detail: http://android-developers.blogspot.com/2013/02/using-cryptog...

The linked article is a bit light on details, so I don't know if this is what they were doing or not. I doubt it though, since that would have meant they were seeding SR with the same value, and I'd like to believe the Bitcoin devs wouldn't make that mistake.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#40

Post by tptacek »

gwillen wrote: post #36
glurgh wrote: post #32

Earlier quoted context omitted.

That's the lib, if you're bored enough to keep diving https://code.google.com/p/bitcoinj/

OK, I dove a little more. The actual signing happens in org.spongycastle.crypto.signers.ECDSASigner . I haven't dug into _that_ yet. But one thing I'm wondering is: would any setSeed on any SecureRandom instance cause a potential problem? Or just on the same instance being used for signing? In other words, do I only need to check that spongycastle -- which I presume is a fork of bouncycastle -- handles things reasona…

Not seeing any relevant code that sets seeds in SpongyCastle, either.
Post reply on HN