On Tue, Jan 5, 2010 at 11:29 AM, Sylvain Munaut <[email protected]> wrote: > > > > 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 > >
Hi, Thanks for good summary Sylvain, for everyone interested the ETSI spec name describing this is 05.02. http://www.3gpp.org/ftp/Specs/html-info/0502.htm Regards Kugg _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
