This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn Sat, Jan 10, 2009 at 01:40:33AM +0100, Holger Freyther wrote: > Hey Guys, > > I'm currently implementing the CM Service Request of GSM 04.08 and I wonder > about the following: > > 1.) Some phones send us the TMSI of their current network > 2.) One can ask the phone for the IMEISV/IMSI > 3.) One can accept the LOCATION UPDATING REQUEST (or wait) > 4.) A rogue MS could now request a channel with the BTS of the original > network > 5.) Could send a CM Service Request with the TMSI of the original phone and > claim to not support A5 and such... > 6.) Could initiate a call on the behalf of the other phone...? I think this would work, if * we had a MS that we could fully control. * the old network would accept the sudden classmark change for no A5 support, which in fact also depends on the cell itself. I would assume that most BTS in real-world netwokrs never announce that they support A5/0 > 7.) What is IMSI detached, I have not yet seen it... but it could solve such The IMSI ATTACH/DETACH procedure is an optional procedure that the BTS can demand by setting some flag in SYSTEM INFORMATION on the BCCH. If enabled, the MS will use a special IMSI ATTACH flag in the location update, and it has to send an IMSI DETACH message before it is switched off. Not sure how useful that really is... but I definitely want support for it in OpenBSC (optionally). Probably time for a config file ;) > what am I missing? These messages are not encrypted right? One just would need > to know the right channel/paging group and such? Is this known? plausible? > totally off? The messages are not encrypted, no. The 'right channel' is the PCH of the other cell. The cell info we get from the LOCATION UPDATING REQUEST (mcc/mnc/lac). The paging group we can calculate from the IMSI. I think the ability to downgrade to A5/0 is the major flaw of this attack. Even if networks allow that now, it's a very simple BSC firmware upgrade to fix it. -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090110/ac1e509e/attachment.bin>