Google Admits Bitcoin Thieves Exploited Android Crypto PRNG Flaw 183
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."
How does this get fixed? (Score:5, Insightful)
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.
Re:How does this get fixed? (Score:5, Informative)
The flaw can be fixed at the application level by manually initializing the PRNG with entropy from /dev/random or /dev/urandom (the built-in tool wasn't doing that properly unless explicitly told to, hence the vulnerability). Some apps will already be immune, and the rest can be patched to fix the problem. An update to Android proper is not required, unless the app isn't updated for some reason (in which case, find a new wallet).
Re: (Score:2)
"The flaw can be fixed at the application level by manually initializing the PRNG with entropy from /dev/random or /dev/urandom (the built-in tool wasn't doing that properly unless explicitly told to, hence the vulnerability)."
Exactly. This doesn't look like an OS flaw at all... people were just using the random number generator improperly.
There are 2 ways to use most PRNGs in software: with a "seed" value and without. In most cases, if you don't initialize with a properly random seed, you're doing it wrong. Un-seeded use might be fine for some games but little else.
Having said that, it could be that the default initialization seed is insecure, and the "patches" change how that behaves. Fine, in that case it's an OS problem
Re: (Score:3)
The flaw is with the OS (or at least with how the OS is intended to work), SecureRandom() on Android is supposed by default to use a cryptographically secure seed to initialize the PRNG (at least, according to the documentation [android.com]. In fact, it's recommended on that documentation page not to seed it yourself). It does not do so, hence the security flaw.
Fortunately, it's extremely easy to fix, but it's still a flaw in Android.
Re: (Score:2)
Re: (Score:3)
I would expect a two pronged attack on this with both a system side fix (for devices that are still getting updates) and application side fixes as app developers try to cover their users regardless of what version of andriod they are using.
Users using non-market apps or apps from vendors who don't get the memo on smartphones that are no longer getting updates will of course be SOL.
Re: (Score:3)
According to the google blog post* the built in SSL stuff is fortunately not affected. So apps that simply act as clients over SSL should be fine. How many applications are there really that need crypto and/or secure random numbers other than SSL. I would think not that many and I would hope that most reputable designers of such applications would have heard about this and be working on an application side fix by now.
* http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html [blogspot.co.uk]
Re: (Score:2)
If only I could give you mod points.
This is without a doubt the big weakness in the android and windows phone markets. People will find exploits in your software, that's inevitable. But this problem of not being able to get updates unless you know how to root your phone and install a new build is just not going to work going forward. We cannot have a computing ecosystem where you cannot get updates unless you have significant technical skill to install them. It's just not going to work and it's going to
Re: (Score:2)
At least in WP's case, the updates come from MS themselves. There are (supposed to be) limits on how long the carriers / OEMs can hold back updates as well. But yeah, for most users the updates won't come as fast as they should.
Still, it's a lot better than on Android.
Re: (Score:2)
This is without a doubt the big weakness in the android and windows phone markets.
I'm not sure that the Apple or Blackberry markets are all that much better. You could buy an iphone 3GS less than a year ago, and Apple has already announced that security vulnerabilities in ios6 aren't going to be patched. And the devices will not be eligible to upgrade to io7.
We're talking several millions of the devices in active use, many of them less than a year old.
Yes, that's not QUITE as bad as Android 2.x devices sitt
Re: (Score:2)
Re: (Score:2)
Which is why, as much as Android is a cool platform, the fragmentation it has gone through has made so many variations as to mean only a small set at any given time have all of the needed updates.
I can almost guarantee you, most cell phone carriers are still selling devices with ancient versions of Android -- and neither the carrier nor the manufacturer gives a damn, they just want you
Re: (Score:2)
Re:How does this get fixed? (Score:4, Insightful)
Which to me pokes holes in the theory this is up to the consumer to be responsible for.
The vast majority of people looking to buy a smart phone won't likely know much about what versions of the OS the phone is running.
It's like selling a product you know might catch fire and kill someone -- you can't just say it's up to the consumer to not buy that model.
Re: (Score:2)
I'm genuinely curious?
I'm still not sure why this is a fragmentation issue. I can run windows on any x64 or i86 machine, I don't need to get security updates from Dell or HP or myself if I built it myself. Why then do I have to get updates to the core os via my carrier?
How is it that for Windows fragmentation was key to them becoming ubiquitous but for Android is becoming a hindrance?
Re: (Score:2)
I'm genuinely curious?
I can't answer that.
I'm still not sure why this is a fragmentation issue. I can run windows on any x64 or i86 machine, I don't need to get security updates from Dell or HP or myself if I built it myself. Why then do I have to get updates to the core os via my carrier?
Because many smartphones (at least in the US) have locked bootloaders, usually at the carrier's insistence. The carrier's want to control the experience on the phones they are selling. Stick with Nexus devices, unlocked developer devices, or easily unlockable devices and you can run custom ROMs and updates to your heart's content.
How is it that for Windows fragmentation was key to them becoming ubiquitous but for Android is becoming a hindrance?
I agree that the Android fragmentation "problem" is grossly overstated. You generally only hear it from fanboys of other OSs, or from clueless analysts who r
Re: (Score:2)
Maybe the fragmentation is why there aren't anywhere near as many Android tablet optimized apps.
http://www.canalys.com/download/tablet_apps.pdf [canalys.com]
Re: (Score:2)
Fault? No, it's definitely Microsoft's fault. They wrote the exploitable code. The duty, legal obligation, sense of honor, or whatever that applies, well that's a different story.
In Google's case, it looks like this is part of the Java stack. No mention of whether this is an exploitable vector in other Java environments. IMO, part of their Android licensing terms should include the mandatory application of security hotfixes by third pa
Re: (Score:2)
Re: (Score:2)
It's much easier and foolproof to fix SecureRandom than to find and change every piece of code (including libraries which many people have no control over) that uses SecureRandom.
Re: (Score:2)
SecureRandom has the benefit of being the standard way of generating random numbers for use in cryptography in Java. Why do it differently when you can do it the standard way (where you can re-use the code later, if opportunity arises)?
On the other hand, "use /dev/random instead" is not good advice for people who already have working code (possibly in libraries) that uses SecureRandom. The solution given in that blog post is very simple: "Add this class to your android project and stick PRNGFixes.apply(); o
Re: (Score:3)
People shouldn't write their own encryption, because even very smart people frequently screw it up
Like Android developers, for instance.
Re:How does this get fixed? (Score:5, Informative)
Why wouldn't you just use /dev/urandom (or better, /dev/random) instead? More layers for more chances to fuck it up?
This is ignorant and needs to be called out.
/dev/(u)random draw on a finite entropy pool. The pool is easily depleted. When there is too little entropy /dev/random blocks on read(2), ruining performance, and /dev/urandom output is cryptographically compromised. From random(4):
The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of data from this device will have a negative impact on other users of the device.
Initializing a CSPRNG such as SecureRandom is exactly the intended purpose of /dev/(u)random.
Cryptography does not belong in the hands of second string hacks like the parent AC. It is possible that /dev/(u)random is a bit too easily abused by fools.
Re: (Score:2)
Has there yet been an actual attack on a high-quality prng (which didn't rely on implementation bugs)?
All I know is that there are several theoretical prngs where predicting the output sequence is NP-hard under the usual crypto assumptions, but I don't know if they are used in practice.
Too many insecure systems ... (Score:5, Insightful)
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.
Caution is never bad (Score:2)
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 probl
Re: (Score:2)
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.
Because breaking the crypto on a hardware/software platform will give you access to thousands, if not millions, of accounts. Social engineering has to be one on a 1 by 1 basis, or via mass spam broadcast, which relies on a lot more factors, including people not just being lazy and ignoring it.
Re: (Score:2)
This is why I wouldn't ever consider having my cell phone be something which can directly access my money.
This is why I actually manage my money.
I have several different accounts, one of which is my "play" account. There's a debit card associated, which I use at bars or gamestop, and can send money from that account via phone if I want... but that account is extremely limited (never over $500) and isn't tied to any bills or recurring payments of any kind. So if that account ever gets compromised, meh, no big deal. The money is insured by the bank, so I'll get it all back... and while the account is in lim
Re: (Score:3)
They already can. Buy online, gas station, etc. How many places actually check your ID or signature?
Re: (Score:2)
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.
/quote>
Only up to a certain point, and if someone does steal your card and start making small $50 transactions the damage is quite limited. Oh and just like if someone steals your card and buys $1000 worth of stuff from the net the liability also sits with the card issuer.
So yes, please sign up for that. That way you're not the dude fumbling with you wallet holding up the queue typing in your pin incorrectly at the terminal while the line behind you gets longer and longer because you fear your money will be taken by the money eating boogieman.
Disclosure: I had my wallet stolen once, $700 worth of transactions appeared on my card. It took 2 phone calls and I got a new card and all my money back.
As for the rest of your comment about security and phones... I fully agree with you. But I agree with you only because there's no defined rules on liability. If the handset manufacturer has legal liability for your loss of funds then I would once again jump on the convenience of making my life simpler and faster at the checkout.
Re: (Score:2)
Also, I highly recommend looking into exactly
Re: (Score:2)
Still only one of 360,000 apps (Score:4, Informative)
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).
Re:Still only one of 360,000 apps (Score:5, Informative)
It isn't programmer negligence in this case, it's the underlying Android implementation. The default constructor is supposed to seed the generator with secure entropy. Conversely, setSeed() is considered insecure and not recommended.
See SecureRandom [android.com]
Someone is gonna say, "I told you so..." (Score:2)
I applaud Google's admission, but sad to note that that the argument will embolden those who've been touting the "fact" [sophos.com] 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?
Re:Someone is gonna say, "I told you so..." (Score:4, Informative)
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.
Re: (Score:3)
There's going to be pros and cons to any financial system.
Problem is that the cons keep getting more and more pro.
Re: (Score:2)
...and then they enter politics.
Bring in the regulators! (Score:5, Funny)
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.
Re: (Score:2)
Re: (Score:2)
That $5720 might not buy you a loaf of bread in 50 years, but it'll still be $5720 and not a cent less.
Why is the industry still using pseudo-randoms? (Score:5, Insightful)
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?
Re:Why is the industry still using pseudo-randoms? (Score:4)
You ask the wrong question. Many embedded CPUs have these devices and with a driver, the Linux kernel uses them. But when the application designers chose to ignore /dev/random (where the kernel exposes its entropy collection), then no amount of good randomness provided by the kernel will help. Incidentally, /dev/random is very good even without hardware RNG, in certain situations you may just have to wait a bit.
The second problem here was that the OpenSSL CPRNG is by its design very much dependent on a good initialization. This is not an obscure or hidden fact, but apparently Google had no competent security people on this project and did not ask any competent 3rd party for an independent review.
Re: (Score:2)
Google had no competent security people on this project and did not ask any competent 3rd party for an independent review.
What does Google care about the security of your data? They have it all anyway.
Re: (Score:2)
Well, Google should care about looking competent. Now they look like clueless morons in public. Which they apparently are.
Re: (Score:2)
OpenSSL is a very convoluted library which evolved organically. Few people understand how to use it properly.
Google peeps regularly contribute significantly to the OpenSSL project. I find it hard to accept this as an excuse.
But I'm guessing the problem here is that OpenSSL's PRNG, even though it is effectively a global singleton, must be _manually_ initialized by the process.
While this used to be the case a long long while ago it has not been true since 0.9.7. Any reasonably current version of openssl (e.g. any version without known vulnerabilities) automatically handles this for you by sucking from /dev/urandom, CryptGenRandom(), etc as needed on major platforms.
I fail to comphrend WTF is going on here. Is /dev/urandom broke? Are they using an ancient version
Re: (Score:2)
You are right that OpenSSL must be manually seeded and that there really is no way around that. But seeding a CPRNG is a difficult thing and any competent user of cryptography will pay special attention to it. I think however, the problem is that when the Java SecureRandom() is used before being seeded, it "self-seeds" and the Java documentation makes no claim at all about the quality of that seeding. True, Google could have made sure to seed from /dev/urandom in this case to protect the unwary. Also true,
Re: (Score:2)
Sun/Oracle have very different documentation for SecureRandom to that in androids API docs.
However the kind of guarentee you ask is not really possible as SecureRandom is part of a service api. That is it can be implemented by a variety of underlying random number generators (psudo or real).
However wrote the service provider for the openSSL initialization on android made a mistake. The android javadocs make this mistake worse as they discourage the use of setSeed saying it may be insecure. Suns docs do not
Re: (Score:2)
You are correct, I was unaware of the different specification for Android.
I disagree on the guarantee though, if it is called "SecureRandom", I think it can well be expected to either be secure or at the very least throw a "no secure implementation available"-kind of exception. Implementing an insecure CPRNG and calling it "SecureRandom" is worse than not implementing it when it cannot be made secure.
Re: (Score:2)
I am not disagreeing with the point the it should self seed securely. I was saying it is nigh on impossible to check a seed to ensure it is secure. So it is not really possible to throw an exception if an insecure seed is used. This should not affect the default constructor (which should be reasonably secure and seems to be on other platforms). The sun docs do suggest (as an example) that this seed should come from a entropy source such a /dev/(u)random for a psudo random number generator.
but if you use a t
Re: (Score:2)
actually Ijust noticed this in the android api docs for Secure Random
"Seeding SecureRandom may be insecure
A seed is an array of bytes used to bootstrap random number generation. To produce cryptographically secure random numbers, both the seed and the algorithm must be secure.
By default, instances of this class will generate an initial seed using an internal entropy source, such as /dev/urandom. This seed is unpredictable and appropriate for secure use.
Using the seeded constructor or calling setSeed(byte[])
Re: (Score:2)
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.
Sure, if you don't mind highly-exploitable biases in your random numbers. Randomness is not enough. You also need to obtain a uniform distribution. Simple hardware designs may also be influenced by external signals, which may be predictable or even controllable by the attacker. The fact that there is some quantum-derived randomness doesn't mean there is no predictability.
Doing this stuff right is hard. /dev/random in the Linux kernel actually does a fine job, better than any cost-effective hardware implem
Re: (Score:2)
"Speed of generation."
I'm willing to bet hardware RNG is still several orders of magnitude faster than "move your mouse randomly" takes.
Re: (Score:2)
Not necessarily, because to get a decent quality unbiased random stream of bits from a simple thermal noise circuit you have to massage it quite a bit. And it may very well be sensitive to external stimuli. For example, a hacker without full access to the device could still run up the CPU and GPU to max load just before you're supposed to generate your secret key, to control the zener temperature.
Not saying it isn't better, but that "it's complicated".
Better to not trust (Score:2, Interesting)
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
Any relation to Seeder (Score:2)
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?
Amateurs. OpenSSL is _not_ the problem. (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
No, it is not. A CPRNG cannot realistically evaluate the quality of the initialization data it is fed with. Sure, it could detect gross non-randomness, but that is it. (Example: Seed it with the time of day, encrypted with AES and key "123456789". That is a very bad seed, but basically impossible to detect without code analysis.)
OpenSSL uses a small-state generator, which is extremely vulnerable to bad seeding. But that fact is not hidden in any way and well-known to experts.
But you are not so wrong
Re: (Score:2)
Are you complaining about the api docs from SUN/Oracle or those from google as they are very different.
Re: (Score:2)
Yes, indeed. I was not aware of the Android version. Having read it now, it is very clear Google messed this up badly/
Re: (Score:2)
Yes, sorry. I was unaware of the android-specific specification.
Re: (Score:2)
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:
According to FAQ if /dev/urandom is there openssl uses it.
http://www.openssl.org/support/faq.html#USER1 [openssl.org]
Re: (Score:2)
Yes, but does the self-seeding of Java SecureRandom() use it too? My guess is it does all OpenSSL seeding itself and does not fall back on the OpenSSL defaults. And the Java documentation for SecureRandom() makes absolutely no statement about the quality of self-seeding.
Re: (Score:2)
Ah, I see. I have looked only into the Oracle Java documentation, not the derived Android Java docs. And Google even warns that setSeed is tricky. The android documentation is much better and fixes the shortcomings of the Oracle documentation, so somebody clearly understood what the issue with the Oracle specification was and fixed it.
But Google messed up badly, as they implemented what the Oracle documentation describes and not what their own fixed documentation does! So, after all, Google _is_ definitely
Re: (Score:2)
Well, in that case they have no clue and their 3rd party had no clue. Hardly makes it any better.
However after having reviewed the SecureRandom() documentation, I think Google is technically in the right. The documentation is fuzzy, unclear and contains as only example a case where SecureRandom() is "self seeded". While it is mentioned that seeding needs to be done with unpredictable data, no statement is made that self-seeding must do this and furthermore, no help on how to correctly seed is provided. I th
Re: (Score:2)
No. Far, far too obvious.
Intel RdRand would have solved this (Score:2)
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.
Re: (Score:2)
That email chain is full of paranoid bullshit. I and one other person designed the random number generator hardware behind RdRand. It's not got any back doors. The NSA doesn't have one. I don't have one. It's been through audit by someone else who probably isn't in bed with the NSA: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf [cryptography.com] .
We built that RNG in order to stop the platform entropy problem that plagues computer crypto systems and to encourage others to do RNGs correctly. So by refu
Re: (Score:3)
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
Only helps if your device... y'know... *updates*.. (Score:2)
Oh, so those 2% of Android devices which are running the latest Droid OS can breathe easy now...
Java has gotten to obscure (Score:3, Interesting)
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.
Re: (Score:2)
> 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.
That's the understatement of the decade. I still remember the experiment I did once to see whether I could get deterministic RSA encryption to work. The idea was to have a private key stored off-server, have a public key stored on-server, and treat the public key-encrypted output like a hash for runtime login purposes, b
Re: (Score:2)
Indeed. Right on the money on all counts. My key experience was that I was wondering when the different AES variants are used, but it was documented nowhere, so after quite a bit of futile searching I was ready to test it out. (I suspect the number of bits in the key were used, but when doing crypto, you need to _know_!) Fortunately the need never materialized, but having users of a crypto-library guess what things do is extremely dangerous. Crypto documentation needs to be even more precise than normal one
Re: (Score:3)
No. The Java documentation is by Oracle/Sun: http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html [oracle.com]
It would however have been a good idea to make sure self-seeding is secure, even if not required by the spec. (It says absolutely nothing about the quality of self-seeding.) That is the only possible fault with Google I can see: They did not protect the unwary and the incompetent. True, the traps set up by the atrociously bad Oracle API documentation are obvious enough to experts that any san
Re: (Score:2)
No the docs for android java are from google and quite different from those from Sun/Orcle
http://developer.android.com/reference/java/security/SecureRandom.html [android.com]
compare to
http://http//docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html [http]
Re: (Score:2)
You are right. I was not aware there was a separate Java documentation for Android. And yes, Google is at fault, because while they fixed the shortcomings of the Oracle specification in their own, they implemented something else, possibly the original Oracle spec.
Just wondering... (Score:2)
How long until Google lawyers will claim that Android users have no expectation of security [cnet.com]?
This is not just a Bitcoin problem (Score:3)
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.
Name one secure system (Score:2)
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.
The fix is no good. (Score:2)
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 v
Re: (Score:2)
In each case that generateSeed() is called, it's also combined with some data from /dev/urandom
Re:Already or in the process of being repaired (Score:5, Interesting)
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.
Re: (Score:2)
So, I would assume if there were other digital wallet type things on Android, they would be subject to the exact same vulnerability.
Unless they open an SSL/TLS connection prior to generating random numbers, or if they aren't dependent on randomness for security (unlikely).
Re: (Score:2)
Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected
The entire crypto on the platform is vulnerable from the looks of it.
That's bad, but it sounds like there's an easy fix. It seems the issue isn't actually with the crypto implementation, but with the initial seed for the randomiser. There are plenty of PRNG libraries for most programming languages, and on a mobile device, there's likely to be other ways of generating entropy - sampling radio static or some such.
Re: (Score:2)
Yeah, so what? Some people think basket weaving is awesome/interesting.
That's probably because it is.
Re: (Score:3)
What has bitcoin done besides assert its own value on the premise that it will somehow be the future of worldwide finance?
Uh, succeed?
Re: (Score:2)
? It's not the first currency to be exchanged nor stored anonymously.
This is true because Bitcoin is not really designed for anonymous exchange. All transactions are public and many points on transactions are publicly known. You have to try pretty hard to be anonymous.
What has bitcoin done besides assert its own value on the premise that it will somehow be the future of worldwide finance?
What Bitcoin added is lack of a single point of centralised control or even distribution. It is a pretty neat cryptographic design which has actually been implemented in real life. Up until recently, the NSA could probably have taken over and destroyed Bitcoin at any time, but since there seem to be quite a
Re: (Score:2)
Normal money works for you. Bitcoin works for some people.
What's wrong with that?
Re: (Score:3)
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.
Re: (Score:2)
it's in the god damn android PRNG initialization of Android and yes, it applies to their Nexus devices though when it's fixed, it will at least be fixed on them.
Please read through my post again. The thing which doesn't apply to a Nexus is the boot loader protection which "protects" you from fixing the Android PRNG yourself (on a Nexus, you can even install alternate ROMS that you can compile yourself [cyanogenmod.org]). You might also want to note my signature.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
According to http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html [blogspot.co.uk]
"Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from /dev/urandom."
Re: (Score:2)
Yes. Everything using Java SecureRandom() on Android is potentially broken.
Re: (Score:2)
I think you could have left out the word 'potentially'.
Re: (Score:2)
Actually, if you seed SecureRandom() (and hence the OpenSSL CPRNG) right, SecureRandom() is perfectly fine. It seems however that the SecureRandom() documentation sucks badly and does not make it clear enough that the resulting random numbers will be unsuitable for cryptographic use unless seeded with enough random bits using setSeed(). To make matters worse, the example given in the documentation implies this is not needed. Hence if people use the example for "typical" use, they will be insecure. Quite fra
Re: (Score:2)
It is my understanding from reading the paper from the security researchers that SecureRandom() is also perfectly fine as long as the implementation does what it's supposed to. In this case, the implementation was buggy, so instead of 256 bits of state they got 56 bits, or something similar. Bits were discarded that shouldn't be.
Re: (Score:2)
It seems the Android Java specification gives far better guarantees than the Oracle Java specification (and is clearer in addition), and you are right, the self-seeding of SeureRandom on Android has to result in a secure seeding.
Re: (Score:2, Insightful)
BitCoin, SchmitCoin!
If this is the kind of stunt being pulled off, it a'int no BitCoin that I worry about.
GooglePay from Android phones. There's where you can make your pennyshaving pay big rewards.
I would run over my phone with a truck, before trusting Android with real account information.