First some little reminders that should shed some light :
The first channel is established something like this :
* Paging request (BTS -> MS on PCH)
* Req channel (MS -> BTS on RACH)
* Assignement (BTS -> MS on CCCH)
* Paging response (MS -> BTS on the assigned channel)
* Cipher mode command (BTS -> MS)
* Cipher mode complete (MS -> BTS [ciphered!])
* ....
The first assignement command establish the first dedicated channel.
* This _can_ be the TCH that will be used for the call (Very Early
assignement).
* Or this can be a SDCCH
* This can already use hopping, but since the assignement is in clear, you
have everything you need to 'follow' it.
If a SDCCH was assigned and the phone needs a TCH (so for a voice call),
then a new different assignement will be done and this one will take place
on the ciphered channel so you can't see it ...
> > 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.
>
See above.
yes you could break encryption with just the first few frames on the
original SDCCH (which is known) but that _will_ need more computational
complexity because you have less plain text -> less chance of finding the
key.
> 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?
>
The hopping has nothing to do with ciphering. It just happens that the
second 'assignement' command that carries what you need to generate the
sequence for the TCH is transfered ciphered.
To know where to listen you need some parameters that are in the
'assignment' command :
- The time slot (doesn't change during hopping)
- The list of channels used by that cell and the subset used for hopping
- Hopping Sequence Number (HSN)
- The 'index' (integer between 0 and N-1)
Some of theses are constant for a given cell (can't really be any other way
if you want to avoid collisions, and observation on real network confirm
this) :
- HSN
- subset of the list of channels used for hopping (usually all but C0)
so if you place a call in that cell yourself, you can get theses easily
before hand. The only remaining unknowns are the timeslot and the index.
> Also this will work only if at every point of time there is a single
> active phone
>
No, you can eliminate channels that had energy before hand. So you need a
single 'new' phone at a time. But granted it's a little far fetched and
would not be the best method for the usrp because the LO would take too much
time to settle anyway. But if you can get the whole spectrum, you can
bruteforce it to try and get more plaintext (the SI5/SI6 messages). This
decouples the problem of getting plain text from getting the hopping
sequence.
Sylvain
_______________________________________________
A51 mailing list
[email protected]
http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
