Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

All Bitcoin Wallets On Android Vulnerable To Theft

samzenpus posted about a year ago | from the protect-ya-neck dept.

Bitcoin 137

judgecorp writes "Bitcoin users have been warned that storing them in a wallet app on Android is insecure, A weakness in Android's random number generator means its random numbers may not be so random, giving attackers a chance of breaking into the wallet. those with Bitcoins have been advised to put them elsewhere, by bitcoin.org"

cancel ×

137 comments

Sorry! There are no comments related to the filter you selected.

How can an OS have such a fundamental problem? (5, Interesting)

Karganeth (1017580) | about a year ago | (#44540749)

It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

Re:How can an OS have such a fundamental problem? (1)

buchner.johannes (1139593) | about a year ago | (#44540779)

It's a pity. Bitcoin would be a powerful payment method on mobile devices, for small amenities (e.g. coffee).

Re:How can an OS have such a fundamental problem? (1)

_merlin (160982) | about a year ago | (#44540827)

Not really - transaction processing takes far to long because the network has to agree on it.

Re:How can an OS have such a fundamental problem? (1)

buchner.johannes (1139593) | about a year ago | (#44540843)

Not really - transaction processing takes far to long because the network has to agree on it.

How long does it take these days?

If the store uses what they would pay as fees to credit card companies as Bitcoin safety, it would probably still pay off. Also, only few people will not pay, especially not returning customers.

Re:How can an OS have such a fundamental problem? (5, Informative)

TheCarp (96830) | about a year ago | (#44541039)

Depends pm what you mean. Any time there are less than, I believe the number is 5400 blocks in two weeks, that the hardness adjusts to attempt to maintain, or about one block every 10 minutes. Technically, if someone can present a valid transaction, you could accept it instantly and say bitcoin has no delay.

Technically the transaction isn't official till its in a block, but once its transmitted out to the network valid, its almost guaranteed to be in one within 10 minutes or so, and each block that buries it, solidifies it further.

What is accepted? Last I looked, the default client didn't consider a transaction accepted until several blocks AFTER it was accepted, so we are talking 20-30 minutes or so.

But.... you could accept bitcoins "instantly" (pretty quick anyway) if you have the most recent block chain, and are sure the transaction has been transmitted out to the public network. There are some small risks in terms of the possibility of accepting a transaction while the block chain is split and a competing transaction being inserted into the other chain, which then wins.... but.... if anyone really does make exploiting such a situation practical and profitable, countermeasures could be achieved pretty easily, it wouldn't be hard to use multiple nodes to watch for block chain splits and monitor what transactions are going out.

Have a few nodes that are not peers of eachother, one transmits the transaction, all the rest watch for it, and watch for splits/competing transactions, etc. I am sure somebody can come up with a pretty safe way to fast accept bitcoins if they haven't already.

Re: How can an OS have such a fundamental problem? (1)

Statecraftsman (718862) | about a year ago | (#44541999)

Just a few corrections. The targeted rate is 2016 blocks per 14 days. The default client allows you to spend incoming coins after one confirmation.

Re:How can an OS have such a fundamental problem? (1)

Anonymous Coward | about a year ago | (#44542141)

NO! You can not accept a transaction without it being in the blockchain, lest you enable the spender to double-spend. It doesn't take a split. The spender can just issue a different transaction on the same sources after you've accepted the transaction and before "your" transaction goes into the blockchain.

Re:How can an OS have such a fundamental problem? (1)

TheCarp (96830) | about a year ago | (#44542621)

Meh, you are right of course, but, there is always some tradeoff between convinence and risk. Yes, theoretically the safe bet is to wait for it to enter the block chain, and even safer, to wait for a few confirmations. You know what though, many transactions that people do, are ones where this level of risk is acceptable because the barrier to cheating outweights the benefit for low value transactions.

I mean seriously, how many vendors accept credit cards now? Do you really think the risk involved with dealing with credit card processors is lower than that of accepting bitcoin transactions instantly? Some amount of risk is always acceptable; its just a matter of where you draw that line.

Frankly, I think it should be possible to reasonably mitigate most of those concerns without much change in the system.

Re: How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44543059)

You are understating the risks, something simple like double spending would be exploited on a large scale and in a hurry.

Re:How can an OS have such a fundamental problem? (1)

IamTheRealMike (537420) | about a year ago | (#44542931)

No, he can't. He can try and race your broadcast, but miners do not accept double spends against the mempool. You can't just arbitrarily replace transactions like that. If you receive an unconfirmed transaction, unless your opponent has a ton of mining power and can choose the exact moment he purchases from you, and the good he's buying is immediately and irreversibly deliverable, it's not typically an issue.

Re:How can an OS have such a fundamental problem? (2)

radiumsoup (741987) | about a year ago | (#44541123)

There are workarounds to this already in use. Bitinstant is one that promises trusted "instant" transactions for bitcoin with specific vendors, although they're reworking their website right now. Others will follow. It'll be a matter of dealing with trusted big-name transaction clearinghouses that settle bitcoin transactions in real-time between their own customers while also transmitting to the network for inclusion in the chain later.

Re:How can an OS have such a fundamental problem? (1)

Tyler Eaves (344284) | about a year ago | (#44542175)

History suggests that you are using a very loose definition of "trusted".

Re:How can an OS have such a fundamental problem? (1)

SlashV (1069110) | about a year ago | (#44542731)

I would say the main advantage of bitcoin is that you *don't need* "big-name transaction clearinghouses". If you use those, you might just as well just pay with your creditcard.

Re:How can an OS have such a fundamental problem? (1)

telchine (719345) | about a year ago | (#44541601)

Not really - transaction processing takes far to long because the network has to agree on it.

I dunno, in a cafe you usually pay after you've eaten. I'd assume the time it takes to drink a coffee would be ample time to have a bitcoin transaction approved.

Re:How can an OS have such a fundamental problem? (1)

killkillkill (884238) | about a year ago | (#44541685)

The effort to create a double spend is not free. For most transaction in day to day life the effort cost and chance involved would be more than the transaction itself, so not worth trying. A transaction propagates through the network pretty much instantly and they can be on their way with a cup of coffee/groceries with less risk than a credit card being charged back. And of course, if you're not paying to Visas rates for the transaction you can afford a bit more risk even if it were present. For a car, internet purchases, an overseas transfer or any large transfer were the risk exists for a profitable double spend; an hour is reasonable to wait for full confirmation of the network.

Re:How can an OS have such a fundamental problem? (1)

DanTheManMS (1039636) | about a year ago | (#44540943)

I imagine that some sort of store-credit type thing would work better for this type of scenario. For instance, while credit cards give you a real-time accepted/denied decision, it still takes days for the transaction to fully process on the back-end. I imagine that Starbucks is a lot more certain that transactions will go through when paid with one of their pre-paid store cards.

It's a bit more inconvenient, I will admit. But it makes commonplace Bitcoin transactions a lot more realistic. And the concept isn't unheard of, actually. When the Bitcoin protocol adapted to make microtransactions unfeasible (as that was never truly the goal of Bitcoin, and microtransactions spam up the blockchain a lot) it basically broke all of the "daily bitcoin faucet" type websites that could no longer be profitable. In response, a third-party website popped up that stores records of your "free daily bitcoin" microtransactions, and outputs an actual Bitcoin payment once it's reached the threshold that makes it profitable again. I think I explained that poorly, for which you must forgive me. It's early on Monday morning after all.

Long story short, while this is a setback, I don't view this exploit as a game-changer, not with the momentum that Bitcoin has behind it right now.

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44540785)

int rnd(){
        return 4;
}

Re:How can an OS have such a fundamental problem? (2)

Saint Gerbil (1155665) | about a year ago | (#44540919)

Number confirmed to be random as certified by a dice roll.

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44540795)

okay

Re:How can an OS have such a fundamental problem? (4, Insightful)

gweihir (88907) | about a year ago | (#44540797)

It is both a solved problem and an ignored problem. I find that I have to explain the risks of not using proper random numbers for anything cryptographic time and again even to customers with experience in using cryptography. I blame the CS and programmer education, which is still badly broken when it comes to security.

Re:How can an OS have such a fundamental problem? (2)

MickLinux (579158) | about a year ago | (#44540893)

Question: would it be correct or incorrect to...

suppose you take your best pseudo-random generated number, and xoror seed it with a word made by stringer together the second-lowest bit each from the temperature gauge, the gps-x the gps-y ,the compass, the ping time, and so on?

Would that #increase# or #decrease# the entropy on the random number generator?

Re:How can an OS have such a fundamental problem? (2, Interesting)

Anonymous Coward | about a year ago | (#44540981)

Question: would it be correct or incorrect to...

suppose you take your best pseudo-random generated number, and xoror seed it with a word made by stringer together the second-lowest bit each from the temperature gauge, the gps-x the gps-y ,the compass, the ping time, and so on?

Would that #increase# or #decrease# the entropy on the random number generator?

It would increase it only if you aren't showing a temp of 32F and a GPS of 00N/00W heading of 0, and a ping of 0 and so on. Seeding from things that arent *surely* good and random is not a smart idea. Why didn't you mention the accelerometers? A program with a little sense to turn on the accels, ask you to shake the phone up a bit, and validate that the results aren't all the same should yield enough to do a good unpredictable RNG seed.

Re:How can an OS have such a fundamental problem? (4, Insightful)

Joce640k (829181) | about a year ago | (#44541009)

The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

(Same as most other cryptographic problems, eg. correctly implementing AES isn't what makes your code secure, it's only the very first step...)

Re:How can an OS have such a fundamental problem? (1)

serviscope_minor (664417) | about a year ago | (#44542329)

The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

You think that, but you have no idea the depths of perversity developers will go to to avoid learning the simple facts that you have internalised.

This developer clearly believed that random numbers do indeed need effort:

http://thedailywtf.com/Articles/Random-Stupidity.aspx [thedailywtf.com]

Re:How can an OS have such a fundamental problem? (1)

WaffleMonster (969671) | about a year ago | (#44542543)

The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

I'm sorry this is unacceptable and dangerous. Expecting developers to get this right is inviting platform failure the same way expecting developers to get SQL and HTML escaping right has earned PHP a certain reputation or expecting Android users to understand the repercussions of allowing n00b0wnrz flashlight app to run on their device has doomed millions of end users to ownage.

In 2013 random numbers should just work by default with no effort on the developers part either by an OS managed entropy pool (e.g. /dev/urandom) and by assist of hardware features (e.g. thermal noise)

(Same as most other cryptographic problems, eg. correctly implementing AES isn't what makes your code secure, it's only the very first step...)

Implementing AES? Understanding high level crypto libraries and not ever calling AES is what gives your code any chance of being secure. The second you call AES you have already failed.

Re:How can an OS have such a fundamental problem? (-1)

Anonymous Coward | about a year ago | (#44540831)

"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number â" there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method." -- John von Neumann.

 

Re:How can an OS have such a fundamental problem? (1)

LordLucless (582312) | about a year ago | (#44540875)

Which is why such methods are called PRNGs - Pseudo-Random Number Generators

Re:How can an OS have such a fundamental problem? (5, Insightful)

bondsbw (888959) | about a year ago | (#44540901)

This doesn't mean you throw in the towel. There are bad PRNG algorithms and better PRNG algorithms, and it's worth using better ones.

Plus, these devices have so many sensors that finding a fairly complex and truly random seed isn't all that difficult. Then throw the seed into a good PRNG and it becomes practically impossible to decode the seed values and, thus, produce any mechanism for finding patterns in the seed data.

Re:How can an OS have such a fundamental problem? (0)

Jumperalex (185007) | about a year ago | (#44541121)

Hmmm not sure that actually works at all. I mean really, I'm not sure. Here's my thinking:

No matter how random the seed is, if you ultimately are pulling from a pseudo random algorithm you have a risk of collisions which iirc is the problem. By your description it would be valid to say, "generate a random seed and then use that to choose from a PRNG that is based on choosing a 0 or 1 depending on the seed's even/odd status" It may be an overly simplistic example, but no matter how complex the PSNG algorithm, or how you seed it, it is ultimately still an algorithm that can allow for generating collision.

But I'm willing to concede I might be missing something in your example. It just seems better to use the random seed in the first place rather than throw it into some PRNG.

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44541689)

Yes. We lose half of the available keyspace (no, not in terms of bits but values) in case the seed is exactly as long as the key and is completely random. Horrors.

Re:How can an OS have such a fundamental problem? (2)

xaxa (988988) | about a year ago | (#44541731)

I'm not a cryptographer, but....

If your random seed really is random, then it's better. But your random source might not be able to provide enough numbers (how often is it sampling the environment?), and according to http://en.wikipedia.org/wiki/Hardware_random_number_generator [wikipedia.org] it's best to constantly check if the numbers are still random.

"collisions" isn't the problem, it's repeating the sequence. (Ask people to draw random dots on paper and they'll often draw quite an even distribution. That's not random!)

There are also uses of random numbers outside cryptography.I came across this: http://en.wikipedia.org/wiki/Mersenne_twister [wikipedia.org] which is good for some uses, but bad for cryptography.

Re:How can an OS have such a fundamental problem? (1)

bondsbw (888959) | about a year ago | (#44542339)

It just seems better to use the random seed in the first place rather than throw it into some PRNG.

You're not incorrect, but it's more of an obfuscation technique. Even natural data that may seem random may be prone to patterns, and sensors all too often have flaws that are unnoticeable for their designed purpose but produce subtle patterns in what would be otherwise purely random data.

My thought is to combine as many flavors of this data as is reasonable, and put it all through cryptographic-strength PRNG to help protect the original seed value and thus the randomness of it. Increased algorithmic strength means you will need to rely on polling sensors less often, which will reduce the likelihood of guessing a new value based on any known device flaws.

Re:How can an OS have such a fundamental problem? (4, Informative)

bill_mcgonigle (4333) | about a year ago | (#44541197)

There are bad PRNG algorithms and better PRNG algorithms, and it's worth using better ones. Plus, these devices have so many sensors that finding a fairly complex and truly random seed isn't all that difficult.

Great insight. I don't understand why linux still uses a known-weak /dev/[u]random when BSD and OSX have used a Yarrow-based PRNG for a decade, and there was even a patch for a Fortuna-based [wikipedia.org] device in the -mm tree at one point.

One of the issues is people say, "just use EGD", but most people don't know about it, don't have it running, and software often uses egd only when /dev/random doesn't exist, if it can use it at all. Having two interfaces isn't the right approach. I can see an argument for leaving something like accelerometer-based entropy gathering in userspace, but as far as I know, there's not a socket setup in place where egd can feed data to /dev/random's pool.

Perhaps we need somebody to grab hold of this issue and drive it forward. Strong crypto is becoming more and more important by the week.

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44541837)

Whoa. I thought linux used yarrow, so I googled about it and it seems it's written by people who know just about enough to be dangerous.

Re: How can an OS have such a fundamental problem? (1)

Anonymous Coward | about a year ago | (#44540977)

"The generation of random numbers is too important to be left to chance." -- Robert R. Coveyou

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44540891)

We won't know until we get actual technical details of the flaw.
Frankly, bitcoin developer incompetence is a safe assumption until proven otherwise, and even then, so I'll hold off judgement of the Android developers until I see the broken code.

Feature not a bug (0)

Anonymous Coward | about a year ago | (#44540935)

Havent you been paying attention to Snowdens releases? This is a NSA "feature" of Android - to protect your freedom, of course.

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44541377)

I'm sure a million monkeys typing would come up with a proper algorithm, in time...

Re:How can an OS have such a fundamental problem? (0)

Anonymous Coward | about a year ago | (#44541483)

Nobody has offered any evidence at all that there's any problem in java.security.SecureRandom on Android.

They've made a bald assertion, and now they promise that they've fixed the problem they just discovered. Well that's nice.

Guy comes into your store, says your cash register is mis-calibrated. You let him open a few drawers, fool around, he closed it all up and says its fixed now.

End of the day your register checks out, but weirdly you've taken about $1000 less than usual. Huh. Maybe there were _two_ miscalbrations and you should invite that guy back. Seems he's left town though.

Re:How can an OS have such a fundamental problem? (1)

telchine (719345) | about a year ago | (#44541551)

It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

To be fair, aren't random numbers genuinely hard to produce with a computer?

I'd have thought that a mobile phone would be a great source of genuinely random data though. Surely tapping into a compass, an accelerometer or a camera could produce genuinely random input?

Re:How can an OS have such a fundamental problem? (1)

tlhIngan (30335) | about a year ago | (#44542453)

It's ridiculous in this day and age that an OS can fail to make random numbers properly. That's one of the most basic operations. How lazy/incompetent are the Google programmers?

Especially since most SoCs used in Android actually have hardware cryptographic accellerators, and one feature of them was a hardware RNG.

Granted, hardware RNGs vary in quality, but most do a very decent job. Even several generations old CPUs have RNG instructions (Intel CPUs, for example - they've had RNGs built in since Core2 days I believe).

Re:How can an OS have such a fundamental problem? (-1)

Anonymous Coward | about a year ago | (#44542583)

not suprising, its Android, right? crappy malware ridden junk!

Re:How can an OS have such a fundamental problem? (1)

SlashV (1069110) | about a year ago | (#44542655)

Have you ever looked at the android source code? I have done some hacking on cyanogenmod and it's amazing what kind of crap can be found in a code base that is being used by several hundred million(!) people..

Re:How can an OS have such a fundamental problem? (2)

kasperd (592156) | about a year ago | (#44542891)

It is build on top of Linux, which has /dev/urandom. I'd like to know if this is a generic kernel bug, or if Android doesn't use /dev/urandom.

You could work around such issues in user code. You could for example have your own 20 byte random seed which you concatenate with 21 bytes from the system random number generator and 14 bytes from other sources (the later don't need to be high entropy, every extra bit helps). Now send the entire 55 bytes through SHA1 and store the output as seed for the next iteration.

Re:How can an OS have such a fundamental problem? (1)

Hentes (2461350) | about a year ago | (#44542895)

There's a tradeoff between security and speed. Android have chosen speed since most apps using a RNG are just games that don't care much about the quality. I guess the philosophy is that apps that rely on cryptographically strong random numbers will make their own RNG or use a third-party one.

Random numbers that aren't random (0)

Anonymous Coward | about a year ago | (#44540761)

are a threat to other cryptographic systems as well, but I'm sure the bug in Android's random number generator was just an honest mistake, even though it is implemented on top of a kernel that already has a working and well-tested random number source.

Exactly (0)

Anonymous Coward | about a year ago | (#44540961)

A nice (extra - over and above Prism) tribute from Google to the NSA. That, or EXTREME incompetence taking a working and well-tested random number source and breaking it.

The bigger issue... (5, Informative)

supersat (639745) | about a year ago | (#44540769)

... is that supposedly Android's "secure" random number generation... isn't. This could potentially affect much more than Bitcoin wallets.

Does anyone know what the issue is? This article [thegenesisblock.com] seems to suggest it's a vulnerability in the SecureRandom class, but no actual details.

Some details (5, Informative)

grimJester (890090) | about a year ago | (#44540931)

Here [bitcoinmagazine.com]

The problem is this: the elliptic curve digital signature algorithm, which Bitcoin transactions rely on for security, has three inputs: the transaction, the signerâ(TM)s private key and a random number. The algorithm then outputs two values, denoted r and s, where s is calculated with the formula k-1(z+rd), z being the hash of the message, k the random number and d the private key. r is dependent only on k. Thus, if the owner of an address signs two transactions with the same random number (and of course the same private key, as every address is linked to one private key), one can extract two s values from the two signatures, subtract them to make the rd terms cancel out, and extracting the private key from there becomes a simple division problem (a more detailed writeup can be found here [nilsschneider.net] ). Normally, this is not a problem; given a true random number generator, the first âoecollisionâ should take place roughly at the same time as the heat death of the universe. As it turned out, however, java.security.SecureRandom proved to be not so random, generating the same âoerandomâ number twice on many occasions.

I just noticed the "found here" link goes to an article from January. That makes me both unsure they've got the right bug and annoyed it hasn't been fixed already.

Re:Some details (5, Informative)

supersat (639745) | about a year ago | (#44541041)

This is exactly how the PS3 got thoroughly 0wned. [schneier.com] I'm curious what the problem with SecureRandom is.

Re:Some details (0)

Anonymous Coward | about a year ago | (#44541463)

Lots of people implement DSA wrong. The post in January was not talking about bitcoin wallet for android— which hardly existed at the time.

Proper implemenation (1)

schneidafunk (795759) | about a year ago | (#44540957)

I am taking a stab that the random generator was not seeded correctly. Here is a good description on seeding properly. [stackoverflow.com]

Re:Proper implemenation (2)

Agent ME (1411269) | about a year ago | (#44541151)

The correct and highest voted answer on that page says to avoid seeding SecureRandom yourself. It's designed to be the most secure with its default constructor. The issue is that Android's implementation of SecureRandom is bad even when you use it correctly.

Re:Proper implemenation (1)

Miamicanes (730264) | about a year ago | (#44541287)

Hmmm. If true, this is *catastrophically* bad, because it clouds the security of EVERY implementation of client-side cryptography under Android.

For years, java.util.SecureRandom has been the bedrock foundation of all encryption under Java (and by extension, Android, even if Android technically isn't Java). A vulnerability in SecureRandom doesn't just bork bitcoins... it screws up things like PBKDF2, DH key exchange (and by extension, SSL & RSA), and even AES (if you're using it client-side to generate a random AES encryption key).

It also means we're probably going to have to NOW mess around with yet another new class, like android.os.ReallySecureRandom (even if the bug DOES get fixed), simply because so many older phones will never see an update, and replacing it entirely with a new RNG class is the only way for an app developer to confidently know that he's not using a degenerate implementation.

Sigh.

Re:Proper implemenation (1)

Agent ME (1411269) | about a year ago | (#44541431)

It is really concerning. I'm hoping that existing SSL/TLS libraries rely on /dev/u?random instead of (in)SecureRandom, or else there might be a lot of stored ciphertext communications getting cracked about now.

At least there's an easy way to patch it in Android apps. Here's the patch [google.com] that works around the issue in the Android Bitcoin client. It patches SecureRandom to just read from /dev/urandom instead.

Re:Proper implemenation (1)

schneidafunk (795759) | about a year ago | (#44542017)

Thanks for the follow-up. I did not realize the default constructor was insecure and this is probably the most informative thread (to me) I've seen on slashdot in a while :)

Re:The bigger issue... (0)

Anonymous Coward | about a year ago | (#44542729)

http://crypto.stackexchange.com/q/9694/706

See the disection on crypto.stackexchange

Random numbers on a mobile device (2)

Kinthelt (96845) | about a year ago | (#44540771)

Shouldn't the RNG tap into the device's accelerometer? That should provide random data if the user gives it a few successive shakes.

Re:Random numbers on a mobile device (4, Insightful)

gweihir (88907) | about a year ago | (#44540801)

The problem is not doing it right once you understand the issue. The problem is understanding the issue.

Re:Random numbers on a mobile device (1)

Thanshin (1188877) | about a year ago | (#44540965)

The problem is not doing it right once you understand the issue. The problem is understanding the issue.

In my experience, the problem is not understanding the issue but either acknowledging there is an issue or even making the effort to investigate whether there might be one.

Re:Random numbers on a mobile device (0)

Anonymous Coward | about a year ago | (#44540971)

Or, you know, use the least significant bits. Grab them from the accelerometer, battery measurement, temperature sensor, microphone, camera and mix them together.
No shaking necessary, thermal noise will make everything jitter as crazy.

Re:Random numbers on a mobile device (0)

Anonymous Coward | about a year ago | (#44541119)

Or, you know, use the least significant bits. Grab them from the accelerometer, battery measurement, temperature sensor, microphone, camera and mix them together.
No shaking necessary, thermal noise will make everything jitter as crazy.

If what i've seen with Google Sky Map is anything to consider, a device with a magnetometer compass makes a damn good RNG after just a few moments of reading.

Re:Random numbers on a mobile device (4, Interesting)

c (8461) | about a year ago | (#44541037)

Shouldn't the RNG tap into the device's accelerometer?

The Linux kernel has has the ability to push device input into the random number entropy pool for a long time (/dev/random and /dev/urandom). If the device drivers aren't pumping accelerometer events into the pool, someone really missed an opportunity.

In this case, it sounds like something went wrong with the Java/Dalvik random number generator. It's not clear to me from glancing at the various write-ups whether it's a failure to RTFM on the part of the Bitcoin wallet writers (or maybe whoever wrote a common Bitcoin reference implementation) or if there's something broken in the Android implementation of the RNG class.

If Android's RNG is kaput... so is Linux's (0)

Anonymous Coward | about a year ago | (#44540783)

After 4.x, all Android versions tend to use /dev/urandom because of blocking issues on /dev/random. If issues with the security of the RNG is at stake, then this is a much larger problem, because anything Linux based is vulnerable.

Re:If Android's RNG is kaput... so is Linux's (0)

Anonymous Coward | about a year ago | (#44540887)

There is a reason /dev/random blocks.

Re:If Android's RNG is kaput... so is Linux's (1)

h4rr4r (612664) | about a year ago | (#44540915)

urandom is not a replacement for /dev/random. /dev/random blocks for a very good reason. Bad Android developer bad! Do it again and I am getting a rolled up newspaper.

Re:If Android's RNG is kaput... so is Linux's (2)

ameen.ross (2498000) | about a year ago | (#44541107)

There's an interesting article over at LWN about /dev/random and /dev/urandom

http://lwn.net/Articles/489734/ [lwn.net]

Re:If Android's RNG is kaput... so is Linux's (2)

Agent ME (1411269) | about a year ago | (#44541161)

The issue is with Android's SecureRandom class. SecureRandom does not rely on /dev/urandom or /dev/random.

Number re-use? (1)

Sockatume (732728) | about a year ago | (#44540791)

There aren't many details floating around but it looks like the issue is that the RNG can return the same number on two occasions. However the possibility of returning the same random number again in the future is a perfectly expected property of any RNG; presumably they mean that the probability is much higher than normal?

Re:Number re-use? (0)

QBasicer (781745) | about a year ago | (#44540829)

It's like random in a CD player, it will repeat songs before it even gets to another. I prefer 'shuffle', where the list is randomized and then played through before reshuffling.

Re:Number re-use? (2)

Sockatume (732728) | about a year ago | (#44540849)

Right. If Bitcoin mistakenly assumed that the RNG "shuffled" numbers and they would not be reused, I don't think that's an Android bug. However given that Bitcoin clients work fine on every other platform I assume that's not the problem and there genuinely is something up with the RNG.

Re:Number re-use? (4, Informative)

Agent ME (1411269) | about a year ago | (#44541185)

The chance of getting the same number twice should be equal to the chance of an attacker brute-forcing it. Judging by the fact some keys were brute-forced in well under a billion years, I'm going to assume it's much more likely that Android's RNG is broken.

Software generated random numbers are never random (1)

Viol8 (599362) | about a year ago | (#44540803)

Since they are generated by algorithms that give repeatable results - this isn't news. The distribution is random (usually) but the sequence is not. You need to tap into some aspect of the hardware if you hope to get true randomness and even then, unless you're measuring some quantum effect the random aspect might not be quite so random as you at first think.

Re:Software generated random numbers are never ran (2)

Sockatume (732728) | about a year ago | (#44540821)

"Arbitrary number generator" might be a more useful name, where the numbers generated follow a given distribution and their selection is arbitrary. Calling them pseudo-random invites mistaken conclusions.

Re:Software generated random numbers are never ran (1)

wonkey_monkey (2592601) | about a year ago | (#44541169)

Calling them pseudo-random invites mistaken conclusions.

Calling them just plain random would be to do that. Pseudo- covers it off nicely, I think. Looks like, but ain't. In fact if the sequence is repeatable (given the same seed), they're demonstrably not arbitrary.

Re:Software generated random numbers are never ran (1)

Agent ME (1411269) | about a year ago | (#44541199)

Good random number generators exist elsewhere. Most modern encryption relies on them. The fact that someone spectacularly messed up an RNG with disastorous exploitable results is news.

Re:Software generated random numbers are never ran (1)

TheCarp (96830) | about a year ago | (#44541867)

Cell phones already have a great RNG, its called the "touch screen"....aka the same RNG thats used to dial random international numbers every time it decides to randomly unlock in your pocket.

Could just have the touch screen polled randomly while the screen is off, if some random portion is being pressed, extract some entropy from it and toss it in the pool. I am pretty sure the interactions between my thigh, pants, and screen could produce every bit as much entropy as wiggling a mouse around.

Bitcoins, Unicorns, lockness monster... (-1)

Anonymous Coward | about a year ago | (#44540807)

You see them pop up in the news, but in the real world, they are never seen.

I'll just leave this here. (0)

Anonymous Coward | about a year ago | (#44540815)

http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

Re:I'll just leave this here. (2)

Sockatume (732728) | about a year ago | (#44540867)

If this random number is ever used twice with the same private key it can be recovered. This transaction was generated by a hardware bitcoin wallet using a pseudo-random number generator that was returning the same “random” number every time.

If this is true there's a vanishingly small but nonzero chance of recovering any private key, depending on how large the random number is; poorly-written RNGs simply increase that chance spectacularly.

Re:I'll just leave this here. (0)

Anonymous Coward | about a year ago | (#44541395)

The random number is as large as the private key, so the chance of recovering any private key it the same as the chance of guessing it correctly.

Not limited to Bitcoin? (1)

L. J. Beauregard (111334) | about a year ago | (#44540865)

If the problem is with Android's RNG, then any secure application on Android may be at risk.

A feature, not a bug (0)

buck-yar (164658) | about a year ago | (#44540905)

Feature required by FISA court, gagged. NSA programmers did the work, in a joint venture with Google.

Secure Your Bitcoins? (0)

Anonymous Coward | about a year ago | (#44540967)

Print the hash out on a piece of paper, say 3x6. Put it in your wallet. Delete the electronic file.

You're welcome.

Re:Secure Your Bitcoins? (0)

Anonymous Coward | about a year ago | (#44541243)

Get wallet stolen, lose all bitcoins. You're an idiot.

Re:Secure Your Bitcoins? (0)

Anonymous Coward | about a year ago | (#44541665)

For better security, use your shoe! (Also, has your wallet ever been stolen?)

Description of vulnerability (1)

schneidafunk (795759) | about a year ago | (#44540987)

Here is an article on how to implement java's securerandom function:

https://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/ [cigital.com]

Re:Description of vulnerability (4, Informative)

Agent ME (1411269) | about a year ago | (#44541263)

By "implement" you mean "use"?

From looking at the Android Bitcoin client's code, it appears it already used SecureRandom correctly (default empty constructor). The Android implementation of SecureRandom itself is broken.

morons (1)

slashmydots (2189826) | about a year ago | (#44541177)

They're already so far beyond stupid for doing it anyway, this is beside the point. If your phone gets stolen or your phone has a hardware failure, your wallet is toast and there goes all your money permanently. Some apps have ways to move your wallet file from a PC to a phone but then it shouldn't have a problem with random number generation since the encrypted wallet came from a PC.

Re:morons (1)

Anonymous Coward | about a year ago | (#44541291)

>If your phone gets stolen or your phone has a hardware failure, your wallet is toast and there goes all your money permanently.

This is why bitcoin wallets allow backup to a file encrypted with a passphrase. If you lose your device, you simply restore your wallet to a new one.

No wonder my craps game always comes up snake eyes (1)

BetaDays (2355424) | about a year ago | (#44541295)

No wonder my craps game always comes up snake eyes.

Re:No wonder my craps game always comes up snake e (0)

Anonymous Coward | about a year ago | (#44542177)

crap is a game? huh? I thought crap is like trash or junk.. like, i hate this crap

Newsflash Rand funciton not so random (-1)

Anonymous Coward | about a year ago | (#44541419)

Researcher finds that the method used by computers to generate random numbers by algorithm isn't truly random. News at 11.

Seriously, how is this news. Anyone who has taken any limited interest in cryptography or computer science knows that a random number generator isn't really random unless it is hooked up to some sort of analog seed source and then most if the time it isn't really random.

Re:Newsflash Rand funciton not so random (0)

Anonymous Coward | about a year ago | (#44542943)

Maybe you should take more than a "limited" interest in something before starting to brag about how clever you are. That way, you might be able to avoid looking like a damn fool who has no clue what the hell he is talking about, like you do now.

NSA strikes again (0)

Anonymous Coward | about a year ago | (#44541683)

If predicable randomness gives access to something you wouldn't normally have access to, then NSA makes the randomness predicable. We should have known by now.

Android is going to hell...... (0)

Anonymous Coward | about a year ago | (#44541695)

First Malware infestation and next the FBI can turn your Mic on and now I can't even have a bitcoin on my device!

Burying the lead (1)

WaffleMonster (969671) | about a year ago | (#44542307)

I have to wonder did someone sit around a table and brainstorm the most innocuous repercussion of RNG failure possible?

"Insecure?" Unsecure? (1)

Control-Z (321144) | about a year ago | (#44543031)

Nitpicky guy here. Wouldn't unsecure be the right word? The meaning of insecure is primarily "Not confident or assured; uncertain or anxious."

Not just a Bitcoin problem (1)

mathimus1863 (1120437) | about a year ago | (#44543069)

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 an entirely-broken random number generator. 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.

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 just from the random variations in sensor output in a dark room.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?