Google confirms critical Android crypto flaw used in Bitcoin heist

[flyt]

And now we simply wait for cell carriers/handset manufacturers to push out updates for all the handsets in the field.

[panarky]

No need to wait for the carriers. Google published sample code for app developers to get good entropy.

http://android-developers.blogspot.com/2013/08/some-securera...

[enraged_camel]

Yep. Everyone who normally pretends that Android fragmentation is "not that big a deal" is going to squirm.

[gsibble]

I'm actually shocked that someone used a zero-day Android exploit to steal $5,700 of BTC. Couldn't they have sold it for significantly more on the black market?

[zorpner]

It may not have been identified specifically as an Android exploit -- there are people (I used to be one of them, though I wouldn't have used the result to exploit wallets) who constantly run crypto attacks on transactions in the blockchain to identify weak wallet keys. The person who stole the BTC probably automated the attack, left it running against the blockchain, and never even knew what the real vulnerability was.

[qnr]

They didn't use an Android exploit specifically, they simply scanned the blockchain for vulnerable private keys. They probably didn't even know that Android was the culprit - it could be hardware wallet, a buggy homebrew client or whatever.

[dspillett]

Depends on the attackers attitude to risk: $5,700 worth of BTC might be a lot harder to track than the sale of an exploit. He doesn't have to trust any other human beings (i.e. the person he is selling to at least) not to dob him in at a moment's notice. A safe 5K might be very much preferable to him than a less safe 20+K.

(caveat: unless otherwise stated numbers in this post, and many of my others, are plucked from thin air)

[mike-cardwell]

I'm more shocked that some people actually trust their phones enough to install bitcoin clients on them.

[cstavish]

It's possible that the exploit was used previously and the incident went unreported.

[kirian]

Yes, $5,700 seems a bargain to uncover a flaw like this. Shows an interesting potential use of bitcoin, can act as a warning system to identify bugs or insecure systems, like a honeypot. If the bitcoins are taken you know there is a weakness somewhere.

[e12e]

We don't really know that. The other obvious implication would be that we now might need new/expanded openssl/ssh key blacklists, for keys generated on Android devices.

[marshray]

Alternatively, someone decided it was worth $5700 to learn whether or not this bug was being exploited in the wild.

[gcb0]

irony of the month: anyone NOT following the age old advice about not implementing your own crypto would have been spared from this.

[lvh]

Why?

This is a failure of the CSPRNG. What "not implementing your own crypto" usually means is trying to cobble together primitives like AES, RSA, and some mode of operation (and, if you're lucky, there's a MAC algorithm in there too), which would still probably have been horribly broken in some way. That's completely orthogonal to this issue.

Are you insinuating that explicitly seeding the CSPRNG with information from the OS' CSPRNG is somehow a bad thing, or that it is frowned upon, or that it constitutes "implementing your own crypto"?

[marshray]

Has anyone looked to see if the NSA Secure Android project has this bug?

[marshray]

I thought OpenSSL's default code already pulled from /dev/[u]random at initialization?

[Afforess]

The Official Sun/Oracle JDK SecureRandom class already pulls from /dev/random. The Android class does not.

[VikingCoder]

How much would a good hardware RNG cost, and when can we have a phone with one that can run Cyanogenmod?

[plasma]

Why does the blog post also suggest /dev/random?

I thought urandom should only be used for crypto.

[aa0]

Random blocks when waiting for entropy. Urandom is "unblocking random" and will return strictly predictable results when the pool becomes drained enough.

[nwh]

Other way around.

[gsibble]

Yeah......that looks like an easy fix o_O