Silicon.fr reporting GSM crypto broken

[[EMAIL PROTECTED] (Ross Anderson)]

Owen:

> Not knowing all that much about phones, would it be possible for companies
> to do that with an over-the-air firmware update or would it need a hardware
> upgrade.  I'd guess the latter (just cos crypto in a phone feels like it
> ought be embedded on the chip in ROM), but I wouldn't honestly know.  Would
> any of the more telephony-minded listers care to exposit?

As I understand it the GSM break is an example of the API attacks that
I discovered a few years back and which have been so well exploited by
Mike Bond and Jolyon Clulow since then.

How it works is this. When you turn on a mobile, it sends its serial
number to the local base station and gets a random challenge back,
RAND. It uses the key Ki in the SIM card to encrypt RAND and the
result is SRES and Kc - the response and the communications key. The
base station tells the phone whether to use A5/1 (hard to break) or
A5/2 (easy), but it's the same key Kc that's used either way, and it's
a deterministic function of RAND and the long-term user key Ki. That's
the flaw.

The attack is as follows. You record a conversation of interest, then
turn on a bogus base station near the target phone. This sees that you
are a stronger signal and tries to register to you. You send it the
value of RAND that you captured; it computes the same SRES and Kc; and
you tell it to use A5/2. It happily does so. You quickly recover Kc by
cryptanalysis. You then use it to decipher the earlier conversation you
recorded.

Can this be fixed by an over-the-air software patch? Probably with
some phones, like the Nokia 3650, where you have complete software
access to the GSM protocols, you could implement a routine to check
whether a particular value of RAND had been seen before. Most phones
are multi-processor and as far as I'm aware it's not possible to
upgrade the software on the chip that does the RF end of things.

An alternative fix is perhaps just never to use A5/2. If a base
station wants to talk A5/2, talk in clear instead. I suspect that this
too could only be implemented on a smallish subset of the fielded
equipment base.

It's an interesting long-tail vulnerability resulting from weak crypto
mandated by governments. If A5/2 hadn't been included in all phones,
so that phones could roam to `dodgy' countries like Bahrein (and
France and Australia :-) then the problem wouldn't have arisen.

For more on API security, see

   http://www.cl.cam.ac.uk/users/mkb23/research/API-Attacks.pdf

(survey paper)

   http://www.cl.cam.ac.uk/ftp/users/rja14/protocols00.pdf

(first paper)

   http://www.cl.cam.ac.uk/ftp/users/rja14/bond-anderson.pdf

(latest paper)

Ross