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."

183 comments

  1. How does this get fixed? by mveloso · · Score: 4, 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.

    1. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      What's most hilarious is the recommended workaround: Seed the "SecureRandom" class with random numbers from /dev/urandom. Seriously? Why wouldn't you just use /dev/urandom (or better, /dev/random) instead? More layers for more chances to fuck it up?

    2. Re:How does this get fixed? by ADRA · · Score: 0

      Its not Microsoft's fault when someone discovers an exploit in Windows 95 and it isn't Google's fault when someone finds faults in unsupported OS's. Smart phones may have faster rev's but they also have shorter shelf lives. Ultimately its the consumer to take the final responsibility for what they do with their devices, and the blame slides away from there.

      I've used google experience phones from day 1 most notably because I know fixes and improvements will be dealt with long into the future. I can't guarantee the same for manufactuers who's bottom line is in direct opposition to maintaining multi-year old devices.

      --
      Bye!
    3. Re:How does this get fixed? by Baloroth · · 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).

      --
      "None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
    4. Re:How does this get fixed? by petermgreen · · Score: 2

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    5. Re:How does this get fixed? by gstoddart · · Score: 1

      I can't guarantee the same for manufactuers who's bottom line is in direct opposition to maintaining multi-year old devices.

      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 to buy another device. When I was getting my current cell phone, they had plenty of Samsung devices running Android 2.x or something, and one lower-spec HTC which was running 4.x and could be upgraded.

      Which is why I decided when I was in the market for an Android tablet to go with the Nexus, because those have the best possible chance of getting updates to fix stuff like this.

      --
      Lost at C:>. Found at C.
    6. Re:How does this get fixed? by FrangoAssado · · Score: 1

      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.

    7. Re:How does this get fixed? by spire3661 · · Score: 1

      MetroPCS will happily sell you a BRAND-NEW Android 2.3 device right now.

      --
      Good-bye
    8. Re:How does this get fixed? by gstoddart · · Score: 3, Insightful

      MetroPCS will happily sell you a BRAND-NEW Android 2.3 device right now.

      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.

      --
      Lost at C:>. Found at C.
    9. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Because when you want to simulating rolling a 6 sided die getting raw bits from /dev/random doesn't work so well.

      The sane thing is for those making Java to use stuff like /dev/urandom and for those using Java to use SecureRandom. That is assuming there aren't further weaknesses in SecureRandom...

      Wasn't Java open? Yet more proof that many eyes does not make security bugs shallow ;).

    10. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      IANAP, and I definitely don't do it on Android but as a layman, I don't think you get the question. Say I was writing a brand new program that needed random numbers. Why would I use SecureRandom instead of just getting the numbers from /dev/urandom? Judging by the workaround, programmers can use either one so what benefit does SecureRandom have?

    11. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Which will never be upgraded.

      Thanks Google & carriers!

    12. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      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.

      So, about 95% of Android users?

    13. Re:How does this get fixed? by petsounds · · Score: 1

      Its not Microsoft's fault when someone discovers an exploit in Windows 95

      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 party vendors, as provided by Google.

    14. Re:How does this get fixed? by petermgreen · · Score: 2

      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

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    15. Re:How does this get fixed? by Tailhook · · Score: 4, 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.

      --
      Maw! Fire up the karma burner!
    16. Re:How does this get fixed? by Sir_Sri · · Score: 1

      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 cost a lot of people a lot of money.

      When MS entered the market with WP8 they should have said 'no carrier interference' like Apple does. I can see Google was trying to be carrier friendly to win marketshare at the time, but this system is not sustainable.

    17. Re:How does this get fixed? by FrangoAssado · · Score: 1

      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(); on your main acvitity's onCreate()." That's a guaranteed fix regardless of whether you're starting a new project or already have working code, and will fix code in libraries you might not even realize are using SecureRandom.

    18. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      /dev/urandom is itself a pseudo-random number generator. Random numbers for cryptographic applications should be random, not pseudo-random. Yes, on many systems, actual randomness is scarce and should not be used where it isn't needed. On the other hand, when you need randomness, don't settle for pseudo-randomness.

    19. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      IANAP, and I definitely don't do it on Android but as a layman, I don't think you get the question. Say I was writing a brand new program that needed random numbers. Why would I use SecureRandom instead of just getting the numbers from /dev/urandom? Judging by the workaround, programmers can use either one so what benefit does SecureRandom have?

      Due to this thing called OOP, SecureRandom is the class that other APIs expect. People shouldn't write their own encryption, because even very smart people frequently screw it up. You use a set of defined libraries and best practices. When there's a bug in the library you update to the fixed library, problem solved.

      Most people will still screw things up, for example using ECB mode instead of knowing when they should switch to CBC mode (hint: nearly always, and if you don't know when you shouldn't use CBC, just use it, you'll be wrong less often).

      This stuff is incredibly hard, you do not roll your own. Finally, while the result of /dev/urandom is good for a seed, you can't exactly use it for a key for example.

    20. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Because when you want to simulating rolling a 6 sided die getting raw bits from /dev/random doesn't work so well.

      The sane thing is for those making Java to use stuff like /dev/urandom and for those using Java to use SecureRandom. That is assuming there aren't further weaknesses in SecureRandom...

      Wasn't Java open? Yet more proof that many eyes does not make security bugs shallow ;).

      Java is open and the bug is in a particular implementation called Dalvik that Google wrote. The Oracle JDK does not have this problem. And security is hard, remember the Debian debacle when they commented out the seed because of the valgrind error? That guy actually asked if anyone saw a problem with it on the mailing list, only one person responded (and that person didn't understand the issue either, given their incorrect response).

      This stuff is harder than most people think it is.

    21. Re:How does this get fixed? by retchdog · · Score: 1

      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.

      --
      "They were pure niggers." – Noam Chomsky
    22. Re:How does this get fixed? by Jane+Q.+Public · · Score: 1

      "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, but a pretty damned minor one.

    23. Re:How does this get fixed? by killkillkill · · Score: 2

      People shouldn't write their own encryption, because even very smart people frequently screw it up

      Like Android developers, for instance.

    24. Re:How does this get fixed? by Baloroth · · Score: 2

      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. 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.

      --
      "None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
    25. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      People shouldn't write their own encryption, because even very smart people frequently screw it up

      Like Android developers, for instance.

      Precisely my point, but to the list we can add a suprising number of companies that are generally considered "best in class". The F ups are seemingly endless. The best we can do is make sure adequate time is in our schedules to implement and review our security and encryption in our apps and have the very smart people put as many eyes on the library implementations as possible.

    26. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      The benefit is, that when an issue is discovered, there's a single point at which it can be fixed.

    27. Re:How does this get fixed? by shawn(at)fsu · · Score: 1

      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?

      --
      500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
    28. Re:How does this get fixed? by cbhacking · · Score: 1

      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.

      --
      There's no place I could be, since I've found Serenity...
    29. Re:How does this get fixed? by vux984 · · Score: 1

      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 sitting on a shelf today. But its not exactly GOOD either, especially given how many iphone 3GS are out there.

      I'm skeptical Blackberry is much better.

    30. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      PRNGs from Haramoto, Matsumoto, Nishimura, Panneton and L’Ecuyer are underused. Have a look at this paper to see the quality of theirs work : http://www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpf2.pdf

    31. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Wasn't there a lawsuit or something about Google using the Java API but not Java. I think they call it Dalvik, which make it Google's fault.

    32. Re:How does this get fixed? by mcl630 · · Score: 1

      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 repeat what others have said. Very rarely do you hear actual Android developers complain about fragmentation problems.

    33. Re:How does this get fixed? by mattack2 · · Score: 1

      Maybe the fragmentation is why there aren't anywhere near as many Android tablet optimized apps.

      http://www.canalys.com/download/tablet_apps.pdf

    34. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Do you even look at what you're linking or are you just happy to see a blurb proving your world view and tune out after that?

      I mean, for example, of course it's the fragmentation's fault the brilliant developer that is Apple, Inc. didn't release all of their applications that are consistently in tops of those ratings for Android. Just make all Android devices run 4.3 - and they'll start working on porting Pages, iBooks and GarageBand to Android, you bet!

      FFS, just let's count - there's 30 unavailable (remember - 12 of those are Apple's own soft) and 5 available, but "unoptimized for tablets" in that list. Which, if you can't or don't want to count, is exactly half of top 100.

    35. Re:How does this get fixed? by thetoadwarrior · · Score: 1

      Buy a new phone. That's what they want and that's what they'll expect and that's your trade-off for buying something cheaper than an iPhone.

    36. Re:How does this get fixed? by thetoadwarrior · · Score: 1

      They only have a shorter life because that's what the companies want. if you buy a cheap bargain phone you get a cheap bargain experience and they'll expect you to come around for another sooner. I still see old 3GS or older iphones. Even blackberry people hold onto their phones but that's two companies that didn't set up their business model on "sell 'em cheap, sell 'em frequently".

    37. Re:How does this get fixed? by Jane+Q.+Public · · Score: 1

      I see. Yes, indeed, if SecureRandom() really isn't, then it's an OS problem.

    38. Re:How does this get fixed? by Anonymous Coward · · Score: 0

      Exactly, that's why you should use /dev/random instead of leaving it to the Android developers to screw it up (which is what you do by using SecureRandom).
      And this specific bug kind of proved that the Android developers are below average when it comes to get it right, so rolling your own might not be that likely to make it worse.

    39. Re:How does this get fixed? by tlhIngan · · Score: 1

      Because the PC is more a monoculture than you think.

      First, an ARM SoC differs between models and manufacturers, whereas a PC is the exact same thing, at least the basics. You can always count on memory being at 0 (because the BIOS (or UEFI BIOS compatibility mode requires copying the MBR and other loaders to low addresses, and then copying expansion ROMs at other addresses, etc), so when you write the initial boot code, it's a lot easier. And before you say MMU hides it all, well, the MMU page tables have to be set up somewhere.

      In addition, other things like peripherals are at known addresses - display is always between 640k-1M initially, serial ports and keyboards are at well known locations, etc.

      An ARM SoC can put memory anywhere - I've seen some put RAM at 0, others at 0x4000_0000, 0x8000_0000, and 0xC000_0000, a serial port can be anywhere in the memory map, as can displays and such. Now, it took over 12 years before Linus got fed up and designed a new boot mechanism for ARM Linux (called device-tree, modeled after OpenFirmware) where the bootloader puts a blob somewhere in memory and the kernel uses it to figure out where the basics are (and it's flexible enough to potentially handle a moving memory map so memory can be relocated, thanks to a lot of careful assembly code).

      The end result is that on the PC, you code for one platform only, while on Android, you have to code for the SoC you're using. And it often happens that the next gen SoC isn't completely compatible so you either pepper the code with #ifdefs or just abandon the old codebase (most common - SoC vendors rarely want to support old SoCs, unless you pay $$$).

      At least Microsoft supports the code for a few years too - SoC vendors typically abandon the old generation code when the next SoC comes out a year later, so manufacturers are pretty much stuck as Android generally keeps up with the Linux kernel but the SoC is abandoned. (SoC vendors rarely push their changes upstream - saves having to deal with Linus' temper and actually submitting nice patches and other things).

      Finally, generally speaking, Microsoft is good at making things "even" API-wse. There are three GPU vendors to consider for 99% of PCs out there (NVidia, AMD, Intel), and their drivers are generally quite good (they don't return fake capabilities). DirectX is relatively mature, and Microsoft does have a quality system in place to test Windows drivers (WHQL), and the APIs are stable for the most part so once you write a driver, you can continue using it down the line (something about Linux and not wanting to commit to even a driver API, nevermind an ABI).

      I suppose if you wanted to make it easy, some things in Android would have to change - stuff like stable ABIs for drivers and such so following the kernel changes isn't difficult, the ability to use an older kernel in Android to save porting time, etc. And perhaps more rigorous testing of the system (right now all they run is CTS, which tests API level, they don't go down and actually drill into drivers and test them for capabilities they advertise and such).

    40. Re:How does this get fixed? by bill_mcgonigle · · Score: 1

      /dev/(u)random draw on a finite entropy pool. The pool is easily depleted.

      Except that on a device with so many real-world sensors, the pool should be easier to keep full. Does Android run esd or equivalent?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    41. Re:How does this get fixed? by mcl630 · · Score: 1

      Maybe the fragmentation is why there aren't anywhere near as many Android tablet optimized apps.

      Umm... no. It's quite easy to have different layouts for larger screens in Android.

      http://www.canalys.com/download/tablet_apps.pdf

      Don't know the relevance of the link you posted. A number of the listed iPad apps that don't have equivalent Android apps are made by Apple, so of course they don't have Android versions. There are very few listed there that have Android versions but are not optimized for tablets, which kinda defeats the fragmentation argument. As someone who owns an Android tablet, I run into very few apps that don't work well on a tablet screen. Most I see *are* optimized for tablets, and many of those that aren't optimized still scale up well enough that it's not a problem.

    42. Re:How does this get fixed? by retchdog · · Score: 1

      That's interesting, but since all it does is make a linear congruence PRNG more efficient, how can you say it's underused? If people needed the efficiency, they would use their PRNG; if they have 50MB (not a whole lot in most cases) to spare, they don't need the extra complexity.

      My question was whether there has been a practical, fundamental attack on PRNGs which wasn't dependent on exploiting an implementation bug. AFAIK, linear congruence PRNGs have not (yet?) been proven NP-hard, but they work in practice.

      --
      "They were pure niggers." – Noam Chomsky
  2. Sorry, honest mistake by Anonymous Coward · · Score: 0

    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.

  3. Too many insecure systems ... by gstoddart · · Score: 4, 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.

    --
    Lost at C:>. Found at C.
    1. Re:Too many insecure systems ... by Anonymous Coward · · Score: 0

      You don't even have to sign for a lot of transactions now. Home Depot $50, Publix supermarket $25 are two examples I get regularly.

    2. Re:Too many insecure systems ... by Anonymous Coward · · Score: 0

      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.

      What difference does it make? I very rarely have anyone look at my signature and compare it to the card. Occasionally, cashiers will ask to look at my drivers license, but not often (and amusingly, asking to see ID if the back of the card is already signed is actually in violation of most merchant agreements).

    3. Re:Too many insecure systems ... by Anonymous Coward · · Score: 0

      You don't even have to sign for a lot of transactions now. Home Depot $50, Publix supermarket $25 are two examples I get regularly.

      At Costco, I've spent almost $200 without having to sign.

    4. Re:Too many insecure systems ... by Anonymous Coward · · Score: 0

      This is why I wouldn't ever consider having my cell phone be something which can directly access my money.

      I agree 100.0% _COMPLETELY_. It's sure as hell not an online wallet, it's a PHONE. I'm upset that if anyone breaks in they can get to my email which contains ONLY EMAIL INFO ALERTS on my billpay status. ("Entergy is billing you $40 this month, will autopay 5 day before due.") I don't want them to even see THAT, and there's no account info or nothing actually there.

          Never mind an actual account statement.

      NFC this!! (Hmmm, now where *DID* gotse wonder off to? ;-) )

    5. Re:Too many insecure systems ... by dpidcoe · · Score: 1

      I've even signed receipts with random things before, unless they have a previous signature from you and are comparing them, the fact that you have to sign when buying with a credit card is pure security theater. And do you honestly think a minimum wage employee is going to turn down a sale because the picture on your drivers license is old and doesn't look like the guy trying to use the card? You're lucky if they even say anything about the names not matching.

      Also, I highly recommend looking into exactly how the agreements are setup between banks/merchants/card companies in order for the entire system to work (find some people who own a business that does card transactions and ask them how it works), it's downright scary how easily the system could be (and often is) abused.

      The system relies almost entirely on security through obscurity and mutual trust. The only reason it hasn't broken down is because there's so much money to be made through the increased commerce resulting from keeping transactions easy to make that the banks and card companies can eat the cost of the occasional abuse.

    6. Re:Too many insecure systems ... by jxander · · Score: 1

      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 limbo, I'm still able to live normally

      --
      This signature is false.
    7. Re:Too many insecure systems ... by mattack2 · · Score: 2

      wow, you mean anybody with my physical card can spend my money without authorization?

      They already can. Buy online, gas station, etc. How many places actually check your ID or signature?

    8. Re:Too many insecure systems ... by OutOnARock · · Score: 1

      Exactly!!!!

      When bank has a "totally free checking acount" promotion, open 2, both with debit visa/mc

      One is "slush fund" feeding the "card in use". when card in use account get compromised, you cancel card and get money back from bank. "slush fund" is untarnished, and it's debit card can be used sparingly.

      transfer funds on phone between two accounts for free......there you go :)

    9. Re:Too many insecure systems ... by Anonymous Coward · · Score: 0

      To be fair, the attacks were carried out with fully public knowledge. If the same flaw existed in a dedicated Bitcoin device which never left the home the money would still have disappeared. I don't see what the bug in SecureRandom() has to do with the ability to connect with 3g networks.

    10. Re:Too many insecure systems ... by thegarbz · · Score: 1

      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.

    11. Re:Too many insecure systems ... by sFurbo · · Score: 1

      It usually isn't your money being spent in this case. At least in my country, if you challenge an expense made in this way, the store will have to produce the receipt. If the signature isn't close enough to what is written on your card, the store gets to pay for the purchase.

  4. Still only one of 360,000 apps by sl4shd0rk · · Score: 3, 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).

    --
    Join the Slashcott! Feb 10 thru Feb 17!
    1. Re:Still only one of 360,000 apps by Anonymous Coward · · Score: 1

      Knowing Symantec and security firms in general, they checked 8 applications, found 4 using SecureRandom and 3 without setSeed, and then did a bit of extrapolation.

      Srsly, there's ~700-800k Android apps in total and they mean to say each one in two required cryptographic random?.. Think of all those fart apps that have an (extremely long but) predictable sequence of farts instead of true random!

      PS: Don't take me wrong, that's a huge security bug, I just hate usual security researchers you-should-totally-buy-our-products-and-services-because-it's-scary-out-there stats.

    2. Re:Still only one of 360,000 apps by GoogleShill · · Score: 4, 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

  5. Re:Already or in the process of being repaired by gstoddart · · Score: 5, Interesting

    This is what you get for playing with bit coin. When are you going to learn?

    You know, it's not even bitcoin.

    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.

    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.
  6. What about banking sites? by Anonymous Coward · · Score: 0

    Everyone is focused on BitCoin, but did this flaw also weaken SSL connections?

    1. Re:What about banking sites? by Anonymous Coward · · Score: 0

      It's an RTFA-hard question there!

      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

    2. Re:What about banking sites? by petermgreen · · Score: 1

      According to http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html

      "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."

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    3. Re:What about banking sites? by gweihir · · Score: 1

      Yes. Everything using Java SecureRandom() on Android is potentially broken.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:What about banking sites? by NatasRevol · · Score: 1

      I think you could have left out the word 'potentially'.

      --
      There are two types of people in the world: Those who crave closure
    5. Re:What about banking sites? by gweihir · · Score: 1

      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 frankly, this broken class documentation is an accident waiting to happen. And now it has happened.

      Of course, this is very bad. It also implies that many people using SecureRandom() have no clue how to use it right. And that is fatal for security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    6. Re:What about banking sites? by pipatron · · Score: 1

      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.

      --
      c++; /* this makes c bigger but returns the old value */
    7. Re:What about banking sites? by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  7. Someone is gonna say, "I told you so..." by bogaboga · · Score: 1

    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?

    1. Re:Someone is gonna say, "I told you so..." by jonyen · · Score: 0

      It's going to take some time. Bitcoin has only been around since 2009. I feel pretty comfortable about doing online banking and using PayPal now, but it took a while to get to that stage. Even before the age of the Internet, there were problems with banking and check scams (ever see "Catch Me If You Can"?). Nothing is ever going to be 100% secure. There's going to be pros and cons to any financial system.

    2. Re:Someone is gonna say, "I told you so..." by aynoknman · · Score: 2

      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.
    3. Re:Someone is gonna say, "I told you so..." by petermgreen · · Score: 3, 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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    4. Re:Someone is gonna say, "I told you so..." by RoknrolZombie · · Score: 1

      ...and then they enter politics.

  8. Bring in the regulators! by meta-monkey · · Score: 4, 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.

    --
    We don't have a state-run media we have a media-run state.
    1. Re:Bring in the regulators! by Linsaran · · Score: 1

      I prefer to keep it in pure gold pressed latinum, the stock market is only good until the collapse of society, latinum is forever.

      --
      In a bit of shameless internet panhandling, I accept Litecoin Donations at Lbd2oH9QsthD1GfuUXPyka12YxvWJYnBVf
    2. Re:Bring in the regulators! by steelfood · · Score: 1

      That $5720 might not buy you a loaf of bread in 50 years, but it'll still be $5720 and not a cent less.

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
    3. Re:Bring in the regulators! by Anonymous Coward · · Score: 0

      While this does seem like a lot of money, keep in mind that this was the total. The attacker took the much smaller balances of a large number of users.

      Even so, Bitcoin could do with lots more regulation. The people should be protected, especially given that Bitcoin is so different to what they are used to.

  9. Why is the industry still using pseudo-randoms? by MrKevvy · · Score: 4, 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?

    --
    -- Insert witty one-liner here. --
    1. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 0

      Speed of generation.

    2. Re:Why is the industry still using pseudo-randoms? by MrKevvy · · Score: 1

      "Speed of generation."

      I'm willing to bet hardware RNG is still several orders of magnitude faster than "move your mouse randomly" takes.

      --
      -- Insert witty one-liner here. --
    3. Re:Why is the industry still using pseudo-randoms? by gweihir · · Score: 3

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 0

      It had to nix'ed after the avalanche breakdown took out a troop of boy scouts during a ski trip.

    5. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 1

      OpenSSL is a very convoluted library which evolved organically. Few people understand how to use it properly.

      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. It doesn't have automatic load-time initialization, probably because there's no portable way to do this in C (Linux and most BSDs support it, but not Solaris AFAIK, and in any event that only works if it's compiled as a dynamic library).

      Even though OpenSSL is a giant PITA, it's still the best thing out there because it's constantly being developed and is kept fairly up-to-date with the latest standards and algorithms. Apple decided to deprecate OpenSSL because of some dubious reasoning about ABI compatibility, and yet over 7 years later they have nothing that comes close to matching the breadth and depth of the OpenSSL API.

    6. Re:Why is the industry still using pseudo-randoms? by WaffleMonster · · Score: 1

      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/fork of openssl? Are they actively seeding the PRNG with predictable garbage when it is not necessary? Either way faulting OpenSSL seems out of line to me.

    7. Re:Why is the industry still using pseudo-randoms? by gweihir · · Score: 1

      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, the documentation of SecureRandom() could have avoided giving example code that use the self-seeding. And Sun/Oracle could have required that self-seeding _must_ be secure or fail with an exception.

      In the end, I think the real root-cause is a convoluted, hard-to-understand API documentation for SecureRandom(), including a misleading example, that is very, very hard to understand for anybody not experienced in the use of cryptography. If they just had said "seed this with enough unpredictable bytes or be insecure" that would probably already have been enough. They did not or rather they did, but not in a way that is clear.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Why is the industry still using pseudo-randoms? by steelfood · · Score: 1

      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.

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
    9. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 0

      The article is still talking about Android, where nearly every device has a set of thermocouples and accelerometers, and the majority have hall effect sensors, GPS, tower/wifi signal strength... all with high precision and only moderate accuracy.

      I do agree that hardware based high-entropy functions would be trivial to add to most devices though.

    10. Re:Why is the industry still using pseudo-randoms? by pipatron · · Score: 1

      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".

      --
      c++; /* this makes c bigger but returns the old value */
    11. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 0

      Rather a lot of them do, though for desktop/laptop computers the hardware RNG tends to be on the motherboard chipset, not the processor. They should be required nowadays, though ATi was rather late to this game.

    12. Re:Why is the industry still using pseudo-randoms? by matfud · · Score: 1

      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 say that. However is is true in that if you provide a dodgy seed you will not have reasonable random numbers generated

    13. Re:Why is the industry still using pseudo-randoms? by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    14. Re:Why is the industry still using pseudo-randoms? by gweihir · · Score: 1

      Well, Google should care about looking competent. Now they look like clueless morons in public. Which they apparently are.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    15. Re:Why is the industry still using pseudo-randoms? by Anonymous Coward · · Score: 0

      Does the temperature sensor for the cpu fluctuate like thermal noise?

    16. Re:Why is the industry still using pseudo-randoms? by swillden · · Score: 1

      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 implementation will. Though, a cheap and biased hardware RNG can be used to help feed the kernel's entropy pool.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    17. Re:Why is the industry still using pseudo-randoms? by matfud · · Score: 1

      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 true random number generator under the hood (as many SOC's do have one) then a seed makes no sense

    18. Re:Why is the industry still using pseudo-randoms? by matfud · · Score: 1

      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[]) may completely replace the cryptographically strong default seed causing the instance to return a predictable sequence of numbers unfit for secure use. Due to variations between implementations it is not recommended to use setSeed at all. "

      So it does appear to be a google bug in the default constructor

  10. Great! by Anonymous Coward · · Score: 0

    ...and will reach the majority of Android users in the next 3-5 years.

    1. Re:Great! by bobbied · · Score: 1

      ... Once they upgrade their current device...

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    2. Re:Great! by Anonymous Coward · · Score: 0

      Bwhahahahahahahha!

      Upgrade how?!?!?!?

    3. Re: Great! by Anonymous Coward · · Score: 0

      Obviously the advantage with iOS devices from Apple is that Apple forces an annual update, by abandoning their older hardware after about a year.

    4. Re: Great! by Anonymous Coward · · Score: 0

      Apple forces an annual update, by abandoning their older hardware after about a year.

      Please stop lying. This has never been true, and what's more, Apple is actually pretty much the best phone/tablet vendor when it comes to long term support.

  11. Obligatory... by Anonymous Coward · · Score: 0

    ...and nothing of value was lost.

  12. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    The bitcoin wallets were already fixed. Now the problem is with everything else...

  13. Better to not trust by m.dillon · · Score: 1, 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

    1. Re:Better to not trust by Anonymous Coward · · Score: 1

      Running your devices through a VPN will do literally nothing to solve this particular problem.

  14. DANGER: DO NOT ALLOW AD BROKERS TO DO YOUR OS !! by Anonymous Coward · · Score: 1

    You can only blame yourselves !! Leave OS design and implementation to the professionals; there is only one name that can be trusted: MicroSoft !!

  15. Re:Already or in the process of being repaired by jeffmflanagan · · Score: 2

    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.

  16. Any relation to Seeder by SleepyHappyDoc · · Score: 1

    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.
  17. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 1

    Including the majority of Android phones, which won't ever be upgraded due to stupid carriers.

    Including most being sold today.

    #Winning

  18. Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 4, 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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      Consider the possibility that they had their "solution" approved by external consultants who know everything there is to know about random numbers and how they pertain to cryptographic systems and their strength, or lack thereof.

    2. Re:Amateurs. OpenSSL is _not_ the problem. by fph+il+quozientatore · · Score: 1

      From what you say, it looks a lot like OpenSSL's fault: why does the RNG work even without proper initialization, allowing users to do the wrong thing in the first place? It should return an error unless safe_init() is called before get_random_number().

      --
      My first program:

      Hell Segmentation fault

    3. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      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 think the people having written this piece of dangerous documentation-trash should be disallowed from ever writing anything technical again. This documentation is worse than no documentation, as it gives wrong impressions that compromise security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      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. When looking at the documentation of Java SecureRandom(), it is not made very clear there that this thing needs to be seeded in a very careful and specific way to be secure. What is worse, is that if it is used without explicit seeding (and the only code example does exactly that!), it "self-seeds", but nothing requires that to be a good seeding in any way. Sure, if Google had been careful/competent, they would have made sure that SecureRandom() is always seeded securely, unless the programmer supplied bad initialization bytes (which can be useful for debugging and other uses). But the real blame in this case is on an atrociously bad API description in the Java API reference. One of many.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      Consider the possibility that it wasn't an accident.

    6. Re:Amateurs. OpenSSL is _not_ the problem. by WaffleMonster · · Score: 1

      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

    7. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      No. Far, far too obvious.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      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.

      http://developer.android.com/reference/java/security/SecureRandom.html

    10. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      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.

      http://developer.android.com/reference/java/security/SecureRandom.html

    11. Re:Amateurs. OpenSSL is _not_ the problem. by matfud · · Score: 1

      Are you complaining about the api docs from SUN/Oracle or those from google as they are very different.

    12. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      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 at fault for this one.

      Thanks for the reference.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    13. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      Yes, indeed. I was not aware of the Android version. Having read it now, it is very clear Google messed this up badly/

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    14. Re:Amateurs. OpenSSL is _not_ the problem. by gweihir · · Score: 1

      Yes, sorry. I was unaware of the android-specific specification.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    15. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      Actually, the cause was far more subtle than your post implies. I'm not sure how much I should say, even though the code is open and the vulnerability has been described, but if you dig into it you'll find that the CPRNG was seeded with good, random data, but with bad timing. In hindsight it's obvious that the CSPRNG was seeded too early, in a way that -- under certain circumstances -- made the outputs predictable by apps on the device (though not by external systems).

      The Android security team includes some world-class security experts -- I know because I've worked with them. This bug arose from a confluence of non-obvious interactions in a complex and changing system, not from incompetence.

    16. Re:Amateurs. OpenSSL is _not_ the problem. by Anonymous Coward · · Score: 0

      Since it was exploitable it almost certainly would have been discoverable by testing. That does very much speak for incompetence, if not straight-out negligence.

  19. Intel RdRand would have solved this by TechyImmigrant · · Score: 1

    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.
    1. Re:Intel RdRand would have solved this by Anonymous Coward · · Score: 0

      Using Intel's RdRand is arguably just as bad:

      http://cryptome.org/2013/07/intel-bed-nsa.htm

    2. Re:Intel RdRand would have solved this by TechyImmigrant · · Score: 1

      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 .

      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 refusing to use the one reliable, built-for-security true random source of entropy in a processor and instead scrapping around with interrupt timing and disk head timing while claiming it is more secure is as stupid as it appears to be.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    3. Re:Intel RdRand would have solved this by Anonymous Coward · · Score: 0

      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.

      And if I worked for NSA that's what I'd say too!~

      Seriously, though, gathering entropy from disk head timings and other common sources is probably not _more secure_, but _as secure as_ RdRand - except decompiling or rebuilding modules to verify that those sources work as claimed is much easier than checking Intel's silicon, so I can see the reasoning for mixing it into entropy pool instead of using it directly.

    4. Re:Intel RdRand would have solved this by TechyImmigrant · · Score: 2

      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.
  20. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 1, Funny

    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.

  21. Only helps if your device... y'know... *updates*.. by jemenake · · Score: 1

    "The flaws are already, or in the process of being repaired..."

    Oh, so those 2% of Android devices which are running the latest Droid OS can breathe easy now...

  22. I know by Anonymous Coward · · Score: 0

    They were misusing the NSA hole in the Android crypto. Smells like inhouse job, maybe Snowden gave the heads up.

  23. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    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?

    The articles says "flaws". That's plural, as in more than 1 flaw. So some of them have already been patched, others are currently being patched. It's really not that difficult to understand the meaning. The only thing wishy-washy is your attention span.

  24. Re:Already or in the process of being repaired by Bam_Thwok · · Score: 1, Informative

    I assure you, he was casting aspersions on all digital wallet type things, not just bitcoin. Bitcoin advocates love to tout how awesomely anonymous and secure and perfect and futuristic it is. Then scams and simple robberies like this happen all the time, and normal people say "caveat emptor, you fool" while the mouthbreathers insist that "It's not a problem with BITCOIN per se! Bitcoin is still great! Bittcoin 4eva!"

  25. happy by Anonymous Coward · · Score: 0

    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.

  26. Java has gotten to obscure by gweihir · · Score: 2, 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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Java has gotten to obscure by Anonymous Coward · · Score: 0

      Yes, perhaps its not Google's fault because maybe the docs suck? Google wrote the code and docs in question didn't they? They are using their own implementation of the JVM even. I don't see how, even if caused by bad docs, this is not Google's fault. They even claim their own code was wrong in this case on their own blog!

      The fact that the CPRNG is supposed to be initialized with enough entropy is part of the spec. The fact that some of their own code for HTTPS didn't rely on this and used setSeed indicates something is strange here. The http code should have also been vulnerable because it should not have been using setSeed, because thats not suppose to help at all and adds a potential place to mess up on all users of the API. They just got lucky in that case that the application level seed setting code is apparently ok, while the library it was overriding that they suggest you use is wrong.

    2. Re:Java has gotten to obscure by gweihir · · Score: 2

      No. The Java documentation is by Oracle/Sun: http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

      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 sane implementation should make sure just copying the example _is_ secure. So if you will, this mess was created by Oracle/Sun in collaboration with Google and people implementing crypto without understanding it and which parts need special attention.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Java has gotten to obscure by Anonymous Coward · · Score: 0

      No. The Java documentation is by Oracle/Sun: http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

      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 sane implementation should make sure just copying the example _is_ secure. So if you will, this mess was created by Oracle/Sun in collaboration with Google and people implementing crypto without understanding it and which parts need special attention.

      Sorry, what? It says plain as day not to seed it yourself.
      http://developer.android.com/reference/java/security/SecureRandom.html

    4. Re:Java has gotten to obscure by Anonymous Coward · · Score: 0

      No. The Dalvik Java documentation is by Google: http://developer.android.com/reference/java/security/SecureRandom.html

    5. Re:Java has gotten to obscure by Miamicanes · · Score: 1

      > 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, but be capable of actual decryption offline if I ever really *had* to do it for some reason (like changing the algorithm, fixing a bug, etc).

      The catch is, RSA intentionally tries to produce NON-deterministic ciphertext. In other words, by design, you can encrypt the same input with the same key a dozen times, and get a dozen different outputs (all of which ultimately decrypt back to the same values). It does, however, have a special mode you can set that explicitly tells it to encrypt in a way that has deterministic output (IE, encrypt the same bytes 16 times with the same key, and get the same output from each run).

      From what I can recall (it was 3-4 years ago), I used IBM's JCE provider... and never, ever got it to work. I'm 99.9% sure it was an outright bug in the library, caused by a flag no real person has probably ever *used*, but it's almost impossible to say for sure, because in an afternoon of Google-searching, I basically came up with 3 or 4 references that even acknowledged that the mode exists.

      This illustrates the main challenge with encryption, and shows why everybody tends to use the same peer-reviewed algorithms and libraries, even when supposedly better alternatives exist... it's damn near *impossible* for anybody who isn't a cryptography researcher to confidently validate stuff like this. At best, you can run unit tests to validate that something works and doesn't crash... but demonstrating more abstract things, like "the encryption keys are strong" is almost impossible to meaningfully do as an individual developer.

    6. Re:Java has gotten to obscure by matfud · · Score: 1

      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
      compare to
      http://http//docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

    7. Re:Java has gotten to obscure by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Java has gotten to obscure by gweihir · · Score: 1

      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, as there are many things you cannot reasonably test.

      The different outputs you observed with RSA was probably random padding, which is just one padding option. In a reasonable library you get at the very least the option to supply your own padding. This is a pretty big deal, as the padding is critical for security and what is secure as padding depends at least in part on what you encrypt and on your concrete application scenario.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  27. Re:Where is Tuppe666? by Jeremiah+Cornelius · · Score: 1, 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.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  28. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    Bitcoin is pretty awesome/interesting. Its experimental as well, so of course there will be bumps in the road. This is the first time open source beat closed source to a market, stop hating on it.

  29. Just wondering... by lxs · · Score: 1

    How long until Google lawyers will claim that Android users have no expectation of security?

  30. Caution is never bad by sjbe · · Score: 1

    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.

    1. Re:Caution is never bad by jxander · · Score: 1

      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.

      --
      This signature is false.
  31. This is not just a Bitcoin problem by mathimus1863 · · Score: 2

    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.

    1. Re:This is not just a Bitcoin problem by Anonymous Coward · · Score: 0

      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...

      The signature is only as strong as the PRNG. If the k value can be guessed, then the private key can be recovered. No need to find two signatures that used the same k.

  32. Name one secure system by WOOFYGOOFY · · Score: 1

    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.

  33. Re:Already or in the process of being repaired by smooth+wombat · · Score: 0

    This is Google we're talking about. The company which openly says you have no privacy.

    This is more proof of their stance.

    --
    We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
  34. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 1

    Bitcoin is pretty awesome/interesting.

    Yeah, so what? Some people think basket weaving is awesome/interesting.

    This is the first time open source beat closed source to a market, stop hating on it.

    On something a majority of people wisely don't use or care about. But, yes, continue to pay yourself on the back.

  35. WTF by Anonymous Coward · · Score: 0

    Why are files from one app available to another?

  36. Re:Already or in the process of being repaired by Bam_Thwok · · Score: 1

    I'll give you that it's interesting. I wouldn't call it awesome, except to say that I'm often awestruck at how relentlessly unscrupulous the bitcoin community remains at every turn. What market is it, exactly, that bitcoin is first to? It's not the first currency to be exchanged nor stored anonymously. It's not the first solution for online person to person or e-commerce payments. It's not the first virtual currency to be exchangeable for real money. Etc. What has bitcoin done besides assert its own value on the premise that it will somehow be the future of worldwide finance?

  37. Re:Already or in the process of being repaired by K.+S.+Kyosuke · · Score: 1

    Yeah, so what? Some people think basket weaving is awesome/interesting.

    That's probably because it is.

    --
    Ezekiel 23:20
  38. Re:Already or in the process of being repaired by rtfa-troll · · Score: 2

    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();
  39. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 1

    I assure you, he was casting aspersions on all physical assets, not just gold. Gold advocates love to tout how awesomely anonymous and secure and perfect and futuristic it is. Then scams and simple robberies like this happen all the time, and normal people say "caveat emptor, you fool" while the mouthbreathers insist that "It's not a problem with GOLD per se! Gold is still great! Golld 4eva!"

    FTFY. The advantage with Bitcoin and similar monetary systems isn't that it's magically immune to theft by granting perfect security. The advantage is that users must pay for and deal with their own security. Had there been a similar flaw in a traditional banking app, the victims would have been reimbursed at everyone else's expense. Your victimization actually is "happening all the time" - your bank account is losing value due to theft right now.

  40. Re:Already or in the process of being repaired by saihung · · Score: 2

    What has bitcoin done besides assert its own value on the premise that it will somehow be the future of worldwide finance?

    Uh, succeed?

  41. Re:Already or in the process of being repaired by fast+turtle · · Score: 1

    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.

    --
    Mod me up/Mod me down: I wont frown as I've no crown
  42. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    It's the first (semi-) widely used digital currency.

  43. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    It's not the first solution for online person to person or e-commerce payments.

    All previous methods relied on a trusted central authority to prevent "double spending", so they arguably weren't person to person... they were person to money transmitter to person. Bitcoin is 100% p2p, no need to trust a central authority for anything whatsoever.

  44. Re:Already or in the process of being repaired by rtfa-troll · · Score: 1

    ? 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 number of ASIC miners working now probably even the NSA doesn't have the compute power to do that and so there's no real way to put Bitcoin back into centralised control.

    There was nothing before Bitcoin that achieved all that.

    Having said that, if someone could do the same but with proper anonymity and some other desirable characteristics there's nothing to say that Bitcoin won't be swapped out some time in the future. No idea what that would do to the value of a Bitcoin. Probably depends on the value of the Bitcoin holdings of the guy who designs the future.

    --
    =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
  45. Dicta Henleiniensis by Anonymous Coward · · Score: 0

    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!

    1. Re:Dicta Henleiniensis by Anonymous Coward · · Score: 0

      > Time to wonder about rolling your own embedded linux, HURD, etc.? Naaah!

      Gnu Cyb0rg is currently under development, 100% open, and should be usable (as long as you don't need working 4G, camera, GPS, Bluetooth, HDMI, or GPU acceleration) by mid-2019. Wi-Fi disabled by default, but if you recompile the kernel to enable NDISWRAPPER, you can kludge it....

  46. The fix is no good. by Animats · · Score: 1

    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.

    1. Re:The fix is no good. by PayPaI · · Score: 1

      In each case that generateSeed() is called, it's also combined with some data from /dev/urandom

    2. Re:The fix is no good. by Anonymous Coward · · Score: 0

      ... And then you'd just have to guess 1024 bytes coming from /dev/random's entropy seeded /dev/urandom. As in:

      // Mix in the device- and invocation-specific seed.
      Class.forName("org.apache.harmony.xnet.provider.jsse.NativeCrypto")
      .getMethod("RAND_seed", byte[].class)
      .invoke(null, generateSeed());
       
      // Mix output of Linux PRNG into OpenSSL's PRNG
      int bytesRead = (Integer) Class.forName(
          "org.apache.harmony.xnet.provider.jsse.NativeCrypto")
      .getMethod("RAND_load_file", String.class, long.class)
      .invoke(null, "/dev/urandom", 1024);

      I'll wait here while you take that foot out of your mouth.

    3. Re:The fix is no good. by Anonymous Coward · · Score: 0

      I might be misreading it, but isn't it stuffing that into /dev/urandom, and then seeding by reading 1024 bytes from /dev/urandom into the pool?
      I think it's probably safer than you say
      Also, If I understood correctly, the problem was that the PRNG wasn't being seeded via random/urandom at all

  47. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 1

    Actually, it almost certainly means that an engineer got told about it, and has claimed that he has fixed it, however, their integration and testing juggernaughts have not yet got round to confirming that it's fixed, and the release schedule doesn't allow for them to send it out right this second.

  48. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    The advantage with Bitcoin and similar monetary systems isn't that it's magically immune to theft by granting perfect security. The advantage is that users must pay for and deal with their own security. Had there been a similar flaw in a traditional banking app, the victims would have been reimbursed at everyone else's expense. Your victimization actually is "happening all the time" - your bank account is losing value due to theft right now.

    OH MY FUCKING GOD MIND BLOWN I WILL TAKE ALL MY MONEY OUT OF MY BANK AND BUY BITCOINS!!!!1!1!!

    Wait, no, I won't. The "value loss" I effectively pay to the bank is how I pay for security, you asshat.

    I realize that it's a matter of faith to libertarians that the world will magically get better if everyone has to be their own police force and army, but the real world doesn't work that way. Study some basic economics (a topic most libertarians are woefully ignorant about despite boasting about how economically intelligent they are) and maybe it'll eventually sink in that specialization increases economic productivity at both the individual and societal level. Securing your own money and property is an example of this -- I will not be better off if I spend lots of my time and attention on money and the protection thereof rather than doing things that I am good at and interested in (in my case, electrical engineering).

  49. Re:Already or in the process of being repaired by rtfa-troll · · Score: 1

    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). You might also want to note my signature.

    --
    =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
  50. This is a devloppers failures by Anonymous Coward · · Score: 0

    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.

  51. Re:Already or in the process of being repaired by swillden · · Score: 1

    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).

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  52. Re:Already or in the process of being repaired by slim · · Score: 1

    Normal money works for you. Bitcoin works for some people.

    What's wrong with that?

  53. Hey I have some imaginary bridges to sell someone by Anonymous Coward · · Score: 0

    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 ???

  54. Re:Already or in the process of being repaired by LordLucless · · Score: 1

    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.

    --
    Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
  55. Re:Already or in the process of being repaired by Anonymous Coward · · Score: 0

    The advantage with Bitcoin and similar monetary systems isn't that it's magically immune to theft by granting perfect security. The advantage is that users must pay for and deal with their own security. Had there been a similar flaw in a traditional banking app, the victims would have been reimbursed at everyone else's expense. Your victimization actually is "happening all the time" - your bank account is losing value due to theft right now.

    OH MY FUCKING GOD MIND BLOWN I WILL TAKE ALL MY MONEY OUT OF MY BANK AND BUY BITCOINS!!!!1!1!!

    Wait, no, I won't. The "value loss" I effectively pay to the bank is how I pay for security, you asshat.

    I realize that it's a matter of faith to libertarians that the world will magically get better if everyone has to be their own police force and army, but the real world doesn't work that way. Study some basic economics (a topic most libertarians are woefully ignorant about despite boasting about how economically intelligent they are) and maybe it'll eventually sink in that specialization increases economic productivity at both the individual and societal level. Securing your own money and property is an example of this -- I will not be better off if I spend lots of my time and attention on money and the protection thereof rather than doing things that I am good at and interested in (in my case, electrical engineering).

    Why do people always think we expect to blow your minds, or that bitcoin is perfect? I didn't insult you.

    Anyways, FWIW I did study some basic economics. You're ignoring the "principal-agent problem" and transaction costs with banks - you have to actually understand how they work and what they do if you don't want to get screwed out of a bunch of money. Do you hire someone to cook all your meals for you and drive you around too, doing no labor whatsoever but electrical engineering? Do bankers hire you to plug their home appliances into electrical sockets? Of course not, because there are some simple things that everyone should be able to do - a cold wallet on a secure machine isn't one of them yet, but as a technical person it's already within your ability.

    I'm a mechanical engineer myself, but it seems painfully obvious even to me that the banks aren't trustworthy and should be cut out of the picture. If you honestly think they're giving you a good deal, by all means keep toiling away in the electricity mines until they tell you that you can retire. You're screaming "Stockholm Syndrome" at everyone.