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."
Where is Tuppe666 to tell us how Google is good for letting this flaw go unfixed for so long.
So what that means is that they aren't repaired, and they will start working on it at some point. Thats a ridiculously wishy-washy statement that has no actual meaning.
This is what you get for playing with bit coin. When are you going to learn?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
Google really had no incentive to screw up the random number generator that would be used by every crypto app on the platform. There are no backdoors, only honest mistakes and bugs.
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!
Everyone is focused on BitCoin, but did this flaw also weaken SSL connections?
I applaud Google's admission, but sad to note that that the argument will embolden those who've been touting the "fact" that iOS is more secure than Android.
I guess one cannot be blamed for saying, "So much for the so called secure open nature of Android."
It just doesn't seem to work...or does it?
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. --
...and will reach the majority of Android users in the next 3-5 years.
...and nothing of value was lost.
Hence why all my Android and iOS devices run a VPN (using the OpenVPN app which works great on both). Of course, the network at the VPN end-point isn't necessarily more secure, but it will be far more secure than all the networks in-between.
The real question here is... will Google at LEAST update all the phones and pads under their own control? Motorola and Nexus updates, please!
-Matt
You can only blame yourselves !! Leave OS design and implementation to the professionals; there is only one name that can be trusted: MicroSoft !!
Someone released an app on XDA, called Seeder, that purports to create entropy to seed the random number generator. Does this have anything to do with that app, or the bug that prompted the developer to write it? I remember when people were discussing the original app (which some people say only has a placebo effect), and they were saying it had security implications...does it make this problem worse or better?
Stasis is death. Embrace change.
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.
If the phones used an Intel SOC, with the RdRand instruction, this would not have happened, because the phone would have over 100MBytes/s of cryptographically secure random numbers from an on chip TRNG, available to software through a single instruction.
ARMs are limited in ways other than just being slow. When it comes to security, these things matter.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Oh, so those 2% of Android devices which are running the latest Droid OS can breathe easy now...
They were misusing the NSA hole in the Android crypto. Smells like inhouse job, maybe Snowden gave the heads up.
My last pay check was $8500 working 10 hours a week online. My younger brother friend has been averaging 12k for months now and he works about 22 hours a week. I can't believe how easy it was once I tried it out. This is what I do, RUN33.COM
Destiny is not a matter of chance; it is a matter of choice. It is not a thing to be waited for; it is a thing to be achieved.
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.
How long until Google lawyers will claim that Android users have no expectation of security?
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.
A sensible and cautious approach. However it isn't all doom and gloom. To encourage customers to use online banking the banks largely have indemnified users against loss due to unauthorized access. The details vary but you typically can get your money back because it is insured or guaranteed by the bank. Might cause a lot of inconvenience but it's doable. It's not really any more or less secure than accessing your bank through a web browser on a PC. Not to say you couldn't be hacked or have some problems but in practical terms it is a manageable problem in practice.
Frankly the soft target isn't your phone, it is your online user name and password. THAT is the point where most people fall down. Why bother breaking they crypto when you can just social engineer or guess your way into the account? Not to say you shouldn't be concerned about the strength of the crypto but it's not what keeps me up at night.
That said if you have an account with a lot of money in it, it isn't a bad idea to isolate that account from the web if practical. You really only need access to a relatively small amount of cash at any given time so why give online thieves an opportunity if you don't truly need online access to the account? I also think debit cards are the work of the devil. A credit card is fine and an ATM card is ok but debit cards are WAY too easy to abuse. If you have a credit card I cannot fathom why you would ever use a debit card.
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.
Just one.
OK then, what does that imply for you ? It's in the current nature of Bitcoin that all your Bitcoins ARE in one basket and you should disaster plan accordingly.
Why are files from one app available to another?
I won't bother /.3rz, of all beings, with the all too obvious Heinlein quote(s).
Suffice it to comment that without all the spammers, jammers, thieves, and assorted low-lifes, a whole dump of vulnerabilities and back-doors would still be happily ticking away out there, just waiting for (and on) big brothers' (state, corporate, private, "religious") sadistic corrupt whims.
BTW do you keep all your eggs in one wallet?
Time to wonder about rolling your own embedded linux, HURD, etc.? Naaah!
The "fix" for this problem is no good. Look at the code.
DataOutputStream seedBufferOut = new DataOutputStream(seedBuffer);
seedBufferOut.writeLong(System.currentTimeMillis());
seedBufferOut.writeLong(System.nanoTime());
seedBufferOut.writeInt(Process.myPid());
seedBufferOut.writeInt(Process.myUid());
seedBufferOut.write(BUILD_FINGERPRINT_AND_DEVICE_SERIAL);
seedBufferOut.close();
How well can we predict those values?
For a program which is initialized when the machine starts, quite well. BUILD_FINGERPRINT_AND_DEVICE_SERIAL is a commonly used device identifier, and is probably being sent in by some apps that "phone home". No entropy there. CurrentTimeMillis is the time and date the machine was powered up. If you guess that was in the last day or so, you'll get a reasonable number of phones. The same is true of nanoTime(), which only has a resolution of milliseconds on Android. Worse, if the crypto library is always initialized shortly after boot, that will always be a small number. MyUID? Probably not too many of those on a phone. MyPid? This is being captured once at startup, so it's probably one of a small number of values.
The easiest attack would be to look for new connections coming from people in airports or leaving movie theaters. They're likely to have just powered up their phone, so nanoTime and myUID are small numbers, and you know roughly what the time was when they powered up. They won't have made many connections yet, so they're near the beginning of the PNG's stream. So the keyspace you have to search isn't that large.
That code almost looks like it was designed to be cryptographically weak. There's not a single source of real randomness there.
the following extract is from the jdk 1.4.2 javadoc, bold is mine :
By using this constructor, the caller obtains a SecureRandom object containing the implementation from the highest-priority installed provider that has a SecureRandom implementation.
Note that this instance of SecureRandom has not been seeded. A call to the setSeed method will seed the SecureRandom object. If a call is not made to setSeed, the first call to the nextBytes method will force the SecureRandom object to seed itself.
This constructor is provided for backwards compatibility. The caller is encouraged to use one of the alternative getInstance methods to obtain a SecureRandom object.
I have some imaginary bridges to sell.
Can I have a list and phone numbers of these people who actually trade real money for these 'bitcoin' things ???