Hi Sylvain, Sascha,

Thank you for corrections. I'm not a great GSM expert and
still learning, you know.

I think it would be great if one placed this kind of information
about frequency hopping into a FAQ on the site. I.e. to answer
the question: "Why GSMA think of hopping as a 'security'
feature and what are the ways to break it?" Or it will confuse
many more people.

On Tue, Jan 5, 2010 at 08:15, sascha <[email protected]> wrote:
> On Tue, Jan 05, 2010 at 07:51:03AM +0300, Alexander Chemeris wrote:
>> Also you *have to* capture full band before you find a key,
>> because you do not know hopping sequence without
>> deciphering. That's why GSMA referred to hopping as
>> a "security feature" - if no ingenious solution is found, you
>> will have to demodulate full band and then apply cracking
>> to all combinations, which increase required computational
>> power by a several orders of magnitude. But probably some
>> ways to reduce required computational power exist. That's
>> the topic for further research.
>
> the computational complexity does not increase because of that.
> what happens is that you break the cipher with the few frames
> that are sent on the original SDCCH after encryption is switched
> on and before a new hopping sequence is negotiated. then you know
> which frames to decrypt with the now known key from the wideband
> capture.

Hum, this contradicts with what I've heard from other people, but
I didn't read this part of specs by myself and can't judge.

On Tue, Jan 5, 2010 at 09:59, Sylvain Munaut <[email protected]> wrote:
>> Also you *have to* capture full band before you find a key,
>> because you do not know hopping sequence without
>> deciphering.
>
> Not entirely true.
>
> 1) If the network uses Very early assignement, you will see the hopping
> sequence parameters in clear
> 2) If you stay on the sdcch (sms), you will see the hopping sequence in
> clear as well

That's interesting, I didn't know this.

> 3) If you know on which BTS your target is (more on that later), you only
> need to spy on the frequencies used by that BTS. And these are available in
> the clear message
> 4) A cell doesn't use the entire spectrum. Actually on the cell in my area,
> I could capture the entire uplink or downlink (not both at the same time)
> with a single USRP1 ...

Yes. Sorry, when I wrote "full band" I should have added "occupied by
a BTS of interest". But this does not change meaning of my original
e-mail, because it's more then one channel and you can't capture it with
one phone. You need SDR device or an array of phones.

> 5) You could try to 'brute force' the hopping parameters by just looking at
> the enery in each timeslot at given time. For a given cell, only the
> 'timeslot' & 'index' changes. But that would need FPGA code changes to just
> get the energy back and not the samples themselves.

hum. I thought that hopping sequence is generated using encryption key
as a parameter. Am I wrong and sequence is the same, and only index in
the sequence is changed?

Also this will work only if at every point of time there is a single
active phone
on the BTS, which is a strong limitation of the technique. Actually I think that
if a target phone is in a non-crowded area, then we don't need to worry a lot
about hopping, because we'll see frames as power spurs on relevant channels.
The trouble is when you're in an area with many phones talking. But in this
case 'victim' can protect himself by calling from, say, 8 phones and obscuring
hopping sequence of main phone.

> PS: To know on which BTS your target is, you can send silent sms (doable via
> some provider on the web) and correlate that with the paging request you see
> on the network to find on which bts he is and his TMSI. If the network isn't
> too busy that would work (and here in my small city, there isnt that many
> paging request so that would be easy).

*nod*
Though this makes attack non-passive.

-- 
Regards,
Alexander Chemeris.
_______________________________________________
A51 mailing list
[email protected]
http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51

Reply via email to