Android random number flaw implicated in Bitcoin thefts

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Bitcoin is often in the news, not least because it is somewhat controversial.

It's a digital currency, backed by cryptography, not by any central issuing authority.

Its "coins" are strings of bits, and anyone can generate one, given enough time (and assuming no-one else generates the same coin first).

The calculations required to "mine" a Bitcoin are configured so that the complexity of finding them doubles every four years.

That means there's an exponential dropoff in the rate at which new Bitcoins appear, and that the supply is capped at 21 million Bitcoins.

The number remaining will quickly close in on zero, with 1/2 gone in 2012, 3/4 by 2016, 7/8 by 2020, and so on.

By about 2030, we'll be close to that asmyptotic maximum of 21 million coins.

For what it's worth, and it is rather a lot, Bitcoin exchanges currently value each Bitcoin (BTC) around US$100.

Now, creating BTCs is one thing, but buying and selling with these digital strings - actually realising that $100/BTC - is quite another matter.

In fact, if you've read any BTC-related horror stories, like the time the value on Mt Gox imploded from $15 to 1c in minutes, or the time Bitfloor was floored by cyberintruders who ran off with $250,000, it almost certainly involved to the trading infrastructure surrounding the Bitcoin algorithms, not the Bitcoin system itself.

Well, it's happened again.

You need somewhere to store your Bitcoins, and a digital wallet that uses public key cryptography is the obvious answer.

Simply put, you can trade in BTCs using an "address", which is actually a public key that others can use to transact with you.

The private key, as usual, you keep to yourself.

As long as you are the only person who knows it , only you can authorise transactions from that address; if you want to sell a Bitcoin sum, you can trade the private key for real money.

That means you need software that will create BTC addresses for you (public-private key pairs), and store your private key safely.

The public key algorithm used in the BTC infrastructure is called ECDSA, short for Elliptic Curve Digital Signature Algorithm.

To cut a long story short, generating a new ECDSA keypair requires you to use a random number between 1 and 2ks - 1, where ks is the key size.

Once you're done, you can discard the random number - indeed, you don't want anyone else to find out what it is.

The mathematical basis of ECDSA means not only that you need the random number in order to go forwards to produce the public and private keys, but also that, with the public key and the random number, you can go backwards to work out the private key.

Of course, that also means your random number should be unique, not just secret, but since you don't keep it lying around after use, how can you ever be sure?

The answer is that the bare minimum officially sanctioned ECDSA key size is 160 bits, so that, at worst, there are 2160 - 1 random values to choose from.

That's about 10 million million million million million million million million, so collisions shouldn't be a problem.

Unless you use a flawed pseudorandom number generator (PRNG), that is.

A PRNG produces an algorithmic sequence of "random" values, which has to start somewhere; if you start from the same place twice, you get the same sequence.

? For some applications, where repeatability is needed, reseeding a PRNG from the same point is a feature, not a bug. Generally, however, you try to seed a PRNG using a bit string that is as close to hardware-random as you can get.

Bitcoin wallet software that re-uses random numbers was found last year by a researcher called Nils Schneider, who documented the computational steps that show why this is a bad thing.

Well, it's happened again.

It looks as though, at least on occasion, the Java-based PRNG on Android will repeat its pseudorandom sequences, thanks to a flaw in Android's so-called SecureRandom Java class.

The Bitcoin Forum has already reported the theft of close to BTC56 (worth about US$6000) from a number of people.

A list of known-vulnerable Android Bitcoin wallets has been published by the Bitcoin Project, with instructions on what to do when the various wallet apps are fixed to use better-quality random numbers.

The Bitcoin Project doesn't go as far as suggesting that you stop using Android altogether to manage your BTC savings.

But perhaps you should consider it?

With two bad security holes recently exposed in Android's digital signature validation for apps, perhaps the platform isn't yet quite ready for the financial big time?

What do you think?

Are you ready to trust Android and Android apps with your hard-earned funds?

Follow @duckblog

You may remain anonymous in Naked Security comments. Just put "Anonymous" as your name and leave the email address blank.

View the original article here

Facebook issues data breach notification - may have leaked your email and phone number

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Facebook just published a data breach notification on its security blog.

You might not immediately notice that from the title of the article, which announces itself as an "Important Message from Facebook's White Hat Program."

But the social networking giant is, indeed, reporting a data leakage problem.

The silver lining is that the quantity of data wrongly disclosed due to Facebook's bug seems to be modest, at least by the standards of a billion-user service.

The cloud (bad pun intended) is that Facebook's systems made the fault possible in the first place.

Facebook, understandably, isn't giving the gory details of the bug and how it could have been exploited, which makes the big picture hard to see.

What it is saying, is this:

We recently received a report to our White Hat program regarding a bug that may have allowed some of a person’s contact information (email or phone number) to be accessed by people who either had some contact information about that person or some connection to them.

So let me tell you what I think the story is all about.

Bear with me, please: I'm going to take a while to set the stage first.

Imagine that Charlie Smith - one of thousands of people with that name - is on Facebook.

He's chosen to tell Facebook his email address, chazza@example.org, but not much more. He hasn't shared where he lives, the name of his employer or his phone number.

Alice joins up and decides to let Facebook at her contact lists. (Facebook squeezes you pretty hard to try to persuade you to upload as much as possible about your web of friends, for reasons that will become obvious in a moment.)

She knows a Charlie Smith; her Charles has a phone number of +1.500.555.5000, and an email address of chazza@example.org.

Facebook can now cross-match the email address and suggest that she might want to try to hook up with Charlie.

Chances are, of all the C. Smiths on Facebook, this is the one she knows.

She sends a Friend Request; it was the right Charlie, and he accepts it.

So far, so good.

Later, Bob comes along.

His contact list, which he yields up to the Facebook empire, identifies a chazza@example.org, known as Charlie Smith, currently living in Someplace, Pennsylvania, and working for the Acme Pointed Stick company.

Facebook likewise puts Bob in touch with Charlie, and thus indirectly with Alice, and the three of them end up as Facebook friends.

Alice is happy; Bob is happy; and, since he agreed to the Friend Requests, we assume Charlie is happy too.

Easy as A-B-C.

Of course, Facebook is the happiest of all, because it now knows (or can make a staggeringly likely guess at) a bunch of personal information about Charlie that he himself chose not to reveal.

Of course, as more people share more information about their contacts, and implicitly confirm the identity of those contacts through the Facebook friendships they forge, Facebook builds up an ever more detailed picture of everyone.

Welcome to the wonderful world of data mining.

You don't have to like this sort of thing, but there's not a lot you can do about it.

Even staying away from sites like Facebook, or "resigning" from them if you're already on, might not help very much.

After all, in our hypothetical example above, Charlie Smith only gave his name and email address; his address, employer and phone number were provided by other people, presumably with their informed consent.

? Alice and Bob may not have thought through the consequences of letting Facebook at their contact lists, but it was their their choice to populate their contact databases with the sort of detail they did, and their choice to let Facebook at that data.

What Facebook seems to be admitting to, in Friday's breach notification message, is that it was careless with the aggregated data accumulated from contact list uploads.

The problem, says Facebook, lay in its Download Your Information (DYI) feature, which exists so you can suck down everything you've previously entrusted to the social networking giant.

Ironically, DYI itself is an important security component of Facebook, because it helps to deal with two serious concerns about cloud-style services:

DYI improves availability, because it allows you to make your own off-site backup of everything you've stored on Facebook.DYI improves transparency, because it acts as a record of everything you've uploaded to Facebook over the years.

But there was a bug in DYI, of the data leakage/unauthorised disclosure sort.

Apparently, DYI was capable of letting you download more than you'd uploaded in the first place.

Using our example above, Bob might have ended up receiving Alice's contact data about Charlie, as well as his own, when he hit the DYI button.

In other words, Bob wouldn't just get back Charlie's address and workplace, which is what he himself uploaded, but might also have ended up with Charlie's phone number, courtesy of Alice.

That's not good at all.

It's especially bad for Charlie, who not only didn't open up his phone number to his Facebook friends, but chose not to upload it in the first place.

Facebook chose to release its statement about this breach on Friday evening, which has already raised the eyebrows of former Naked Security denizen Graham Cluley.

Friday nights, he argues, are the traditional time for burying the sort of announcements you make of necessity rather than by choice.

You can see why Facebook might want this to be a weekend story: there's a chance that it might cause some companies to rethink their "Facebook at Work" strategies, and go back to the old days where Facebook was blocked outright.

That would put a dent in Facebook's daytime traffic, for sure.

After all, if someone shares their contact list while they're at work, they might end up sharing a whole lot more, about many more people, than they really intended.

And Facebook just admitted that, somewhere in its cloud, was a bug that prevented it from taking proper care of that data.

Facebook turned off DYI once the bug was disclosed, fixed it, turned DYI back on again, and published its data breach notification.

Even if you take a cynical view of the timing and the title of the notification, I think you should be happy about some aspects of this cautionary tale:

Respect to the finder of the bug for disclosing it responsibly to Facebook so it could be fixed, even though he'd probably have got a lot more publicity if he'd told the world first.Thanks to Facebook for having a bug bounty programme so that the finder gets some sort of reward for doing the right thing.Well done to Facebook for taking the bug report seriously and fixing the problem.Congratulations to those jurisdictions that have passed strong data breach notification laws, so that this sort of problem can't just be swept under the carpet.Huzzah to those of you who take the stance of not sharing contact lists with social networking sites, on the principle that "if you don't share it, they can't lose it."

Follow @duckblog

View the original article here