Slashdot Mirror
Google Admits Bitcoin Thieves Exploited Android Crypto PRNG Flaw
rjmarvin writes "The theft of 55 Bitcoins, or about $5,720, through Android wallet apps last week was made possible because of flaws in Android's Java and OpenSSL crypto PRNG, Google revealed in a blog post. In the wake of a Bitcoin security advisory and a Symantec vulnerability report, the Android Developers Blog admitted the reason the thieves were able to pilfer their wallet apps. The flaws are already, or in the process of being repaired."
Is it up to the OEM to backport the patch to all the various android versions that they have? If so, this vulnerability will live forever.
It's like google and its partners are building this huge botnet of vulnerable devices. Every year it gets bigger.
This is why I wouldn't ever consider having my cell phone be something which can directly access my money.
I don't trust the makers to competently build in security, and I believe that once everyone knows your cell phone is likely to be tied to your bank account, it's a soft target.
They keep trying to find new ways to make it more 'convenient' to use these things to spend money, but 'convenient' in this case means insecure and fraught with privacy issues (and extra service fees if they can get away with it).
Same with that tap to pay mechanism ... wow, you mean anybody with my physical card can spend my money without authorization? Gee, sign me up for that.
Tech companies want to make a product or app for pretty much everything -- and a lot of them I find myself asking "who would want that?".
Now, mind the steps while you're leaving my lawn, and don't trip on the sprinkler.
Lost at C:>. Found at C.
FTFA: security researchers from Symantec issued a report on upwards of 360,000 apps using the SecureRandom class, containing the PRNG flaw in Bitcoinâ(TM)s Elliptic Curve Digital Signature Algorithm (ECDSA).
May give a potential indication at the sheer number of applications affected by this exploit (which is programmer negligence apparently). Drilling into the Symantec article reveals how they arrived at that number.
we have found over 360,000 applications that make use of SecureRandom and over 320,000 of them use SecureRandom in the same way the bitcoin wallets did (they did not call setSeed).
Join the Slashcott! Feb 10 thru Feb 17!
You know, it's not even bitcoin.
The entire crypto on the platform is vulnerable from the looks of it.
So, I would assume if there were other digital wallet type things on Android, they would be subject to the exact same vulnerability.
Lost at C:>. Found at C.
I'm so glad they're going to start regulating bitcoin. I mean, somebody ran off with $5,720! Monstrous!
That's why I keep my money in safe, secure U.S. dollars and in the stock market, where you don't have to worry about dangerous criminals absconding with your savings.
We don't have a state-run media we have a media-run state.
True random numbers are as simple as a reversed Zener diode connected to an A/D converter... quantum tunneling across the diode creates truly random signal, equivalent to thermal noise.
So why isn't every CPU nowadays equipped with this, so that the RND function is done in hardware?
-- Insert witty one-liner here. --
No, it means that devs jumped on the problem as soon as it was revealed, and at least the Android wallet I use has already been patched, and a new bitcoin address automatically created to secure my precious .0006BTC. I assume that's the case for most, if not all, Android wallets.
Nothing you said was true. so you might want to consider the possibility that you don't know what you're talking about and are spreading FUD.
This is not an OpenSSL-flaw. Proper initialization of a CPRNG is critical and the OpenSSL documentation states that. The choice of OpenSSL is however especially bad with a bad initialization, as the OpenSSL CPRNG does not continue to seed the generator with additional entropy during its operation, unlike /dev/random or /dev/urandom. Google messed up spectacularly in two regards:
1. They had nobody that understood secure random number generation on the team
2. They did not have their solution independently reviewed by a competent 3rd party
They also selected a CPRNG especially vulnerable to bad seeding and did not use a source of good seeding readily available.
These mistakes are on low amateur level when implementing cryptographic functionality. The dangers of bad CPRNG seeding have been well understood for decades. This looks like the all-to-often found mixture of incompetence and arrogance.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There's going to be pros and cons to any financial system.
Problem is that the cons keep getting more and more pro.
We need a "+1 -- nice sig" moderation.
One big security problem with andriod is the distribution model. Google makes andriod and distributes it to their OEM partners (and to the general public though sometimes with a delay). The OEMs then customise it and pass it on to their users and in most cases (nexus excepted) all updates go through the OEM.
The result is you get the situation of there being lots of older smartphones out there that are still perfectly usable but are no longer able to receive security updates in the regular manner because the OEM can no longer be bothered updating them. Sometimes it's possible to unlock the bootloader and install an unofficial build but that is at best something that requires you to be fairly technical and at worst something where even a computer expert like me can find myself in a dead end*.
* For example htc officially offers a bootloader unlock process but when I tried it on my brother's old wildfire the software version on it was too new to apply the RUU needed for the bootloader unlock process.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Or rather the Java libraries and their documentation. My guess is that nobody working on this application even noticed that they did seed SecureRandom wrongly. At the same time, making sure this class is always seeded securely (which the spec would allow and would cause negligible overhead) would have been the right thing to do. But after looking at the problem in more detail, I am not so sure anymore this mistake by Google is the root-cause. It is also quite possible that Java programmers in general have stopped caring how classes do things internally, as long as they seem to work. The documentation for the Java crypto API is certainly convoluted and uninformative enough to be rather painful to read and left me wondering what the different methods actually do.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This certainly affects Bitcoin the most, but a random number generator that actually produces the same "random" numbers is hardly random at all, and could present a serious problem for all types of applications. In fact, that's a thoroughly-broken random number generator and all crypto-related operations could be hosed. I'm wondering how such an egregious PRNG/seeding-algo made it this long without someone noticing. Maybe it's because Bitcoin provides a financial incentive to find these flaws, and honestly it's pretty easy to spot it from a one-minute blockchain scan -- just look for two transactions with identical r-values, plug it into the stupid-simple equation, and then steal the money.
This has actually come up in the Bitcoin space before: people were rolling-their-own-ECDSA for constructing and signing transactions, and were not aware of the importance of using different random numbers for every signature. As such, about a year ago someone did an identical blockchain search and was able to steal coins the exact same way: but it was due to script-kiddie ignorance. It was assumed this problem would go away when you start using the system PRNG, and taught people a lesson about rolling-their-own-crypto. Even if it's a weak system PRNG, the ECDSA signatures are fairly strong as long as the numbers are different between signatures. Apparently this was more than just "weak" though...
For Android/mobile, the answer is to leverage the variety of sensors that are on-board. Using the low bits of accelerometer output should work great for seeding a PRNG if someone is actually holding the phone. If not, snap an image or take a quarter-second audio recording should suffice. There's enough noise on the camera and microphone that the hash of the output should be different even if it's sitting camera down in a quiet room. A lot of times you only 32-bytes of entropy, and a single image with 5 million pixels can give you an order of magnitude more than that just from the random variations in sensor output in a dark room.
It's okay though, with Android you can just write your own PRNG and change all the other software to use it, then you'll be good to go.
It's even better than that though. You can write it; but Google carefully thought to protect you from actually deploying it by putting Android under the Apache license which means that your phone manufacturer can lock down your bootloader to protect you from actually changing anything. Just think of all the people who might end up putting insecure random number generators into their phone and screwing their security if Google had used, for example, the GPLv3.
All hail the all knowing and all wise Google.
(I will admit that at least Google's own Nexus devices don't really do this; but why spoil a good rant with facts.. )
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
What has bitcoin done besides assert its own value on the premise that it will somehow be the future of worldwide finance?
Uh, succeed?
It isn't as secure because the entropy gathering and processing all takes place in memory, subject to memory and software attacks of various forms.
The point of putting the entropy extraction, OHT, BIST and CSPRNG behind a fips 140-2 compliant boundary was so that it wasn't subject to those attacks and the random numbers would be delivered directly into the register space of the running application.
You can mix sources all you like, but if you're increasing the attack surface while you do, then you have made things worse.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.