Re: OsmocomBB MNCC socket implementation without LCR
Hi Gerard, On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote: > 1) Have you or your team tried to reverse engineer/hacking Over the Air OTA > spec - firmware upgrade (understanding this type of communication) using > OpenNITB and latest phones where bootloaders are locked? I haven't looked at this personally, but several people have looked at security of several different OTA updates for about a decade by now. The main issue is that there is no standard protocol or system, and everyone cooks up their own. > - I was planning to try this! But now I will take up merging osmo-sim-auth > and py-sim. (I'm not a great dev but I'm passionate about osmocom and > willing to contribute my time to learning/contributing the same). thanks! > 2) I have been trying something different with OsmocomBB, osmo-sim-auth and > Tor lately - I would like to hear your views on the same. > Attack Model: Geo-Location Anonymous calling in GSM. > > Description: > 1. The attacker uses OsmocomBB phone to make a call using a sim card > service. (No sim card present in the phone). > 2. For this, I have taken the SIM card outside OsmocomBB and re-written all > SIM API's in osmo-sim-auth (which is the sim card service). > 3. This sim card service is deployed over Tor network, so no one can > actually know the location of the SIM card service. > 4, The osmocombb connects to the network and uses this sim card service for > authentication etc. > 5. The whole setup of calling etc is initiated by the sim card service, > which is itself behind Tor. This is basically the sim card forwarding / remote SIM, which people have been experimenting on SIMtrace for quite some time. In this case you can use any regular phone or modem, and don't need osmocombb. There is a complete 'remote sim / card emulation' proof of concept in the simtrace2.git repository, but this requires a prototype of the simtrace 2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware (with SAM7). Also, there are plenty of commercial suppliers of systems like you have described. a) in the area of automatic roaming testing (between operators) b) in the area of automatic service quality testing (between operators) c) in the grey area of so-called SIM-boxes, where you have hundreds to thousands of SIM cards in one data center, which you can remotely provision to any number of "GSM VoIP gateways" spread in different countries. This is typically used for interconnection fraud by shady operators. None of the above use Tor (as they have different use cases), but the option 'c' at least also uses IMEI randomization to avoid tracking the subscriber via his IMEI, which presumably you would want to do in your OsmocomBB based system, t.. > 6. Now, This SIM card service can be used my multiple phones, so now you > are not exactly going to track the phone since if I use the SIM card > service to another phone (cell area) the DB entry in VLR has changed which > says the location has changed. Yes, but you have to be very quick. Of course from the time of the LU throughout the call, your position is known to the observer. Not because of your IMSI or IMEI (which you both keep changing) but because of the phone numbers you call. It depends on what you want to defend against. Basically you can do this already if you carry around a huge bag of sim cards which you always only use for a single call, *and* you have a phone that can change the IMEI every time you change the SIM. This is apparently what e.g. human rights activists in hostile countries are doing. However, the biggest problem in such situations is not your own identity, but the identities you contact. So if you keep calling the same destination number, all of the above is useless as the key to find you is by the destination number. So at the same time, you require a potentially large number of phone numbers that are not in some way associated to another (and at best in different countries), which then provide call redirect to your real destination. > 7. My experiments worked well on a LIVE network, understanding the delay in > Tor the network, still, the BTS was accepting RES response challenge from > the SIM card service behind Tor - I still have to calculate the exact max > acceptable delay in sending RES back to BTS to confirm this! I think I remember that at least 2 if not 4 seconds of delay are acceptable for the complete authentication handshake. People are even doing this over satellite back-haul. -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB MNCC socket implementation without LCR
Hi Gerard 2017. márc. 28. dátummal, 9:10 időpontban Gerard Pinto írta: > 2) I have been trying something different with OsmocomBB, osmo-sim-auth and > Tor lately - I would like to hear your views on the same. > Attack Model: Geo-Location Anonymous calling in GSM. > > Description: > 1. The attacker uses OsmocomBB phone to make a call using a sim card service. > (No sim card present in the phone). > 2. For this, I have taken the SIM card outside OsmocomBB and re-written all > SIM API's in osmo-sim-auth (which is the sim card service). > 3. This sim card service is deployed over Tor network, so no one can actually > know the location of the SIM card service. > 4, The osmocombb connects to the network and uses this sim card service for > authentication etc. > 5. The whole setup of calling etc is initiated by the sim card service, which > is itself behind Tor. > > 6. Now, This SIM card service can be used my multiple phones, so now you are > not exactly going to track the phone since if I use the SIM card service to > another phone (cell area) the DB entry in VLR has changed which says the > location has changed. > 7. My experiments worked well on a LIVE network, understanding the delay in > Tor the network, still, the BTS was accepting RES response challenge from the > SIM card service behind Tor - I still have to calculate the exact max > acceptable delay in sending RES back to BTS to confirm this! This is a very interesting idea, I like it! I wanted to mention the SAP protocol that is available in OsmocomBB's mobile app via a Unix domain socket since some time now. It might be even easier to use it for your idea. I used it via an external card reader and softSIM to provide a SIM card for OsmocomBB. Cheers, Domi
Re: OsmocomBB MNCC socket implementation without LCR
Hi Herald, Thank you for your responses. I appreciate you taking out time from your schedule. Just a couple of things I would like to share since my interest grew in telecom. 1) Have you or your team tried to reverse engineer/hacking Over the Air OTA spec - firmware upgrade (understanding this type of communication) using OpenNITB and latest phones where bootloaders are locked? - I was planning to try this! But now I will take up merging osmo-sim-auth and py-sim. (I'm not a great dev but I'm passionate about osmocom and willing to contribute my time to learning/contributing the same). 2) I have been trying something different with OsmocomBB, osmo-sim-auth and Tor lately - I would like to hear your views on the same. Attack Model: Geo-Location Anonymous calling in GSM. Description: 1. The attacker uses OsmocomBB phone to make a call using a sim card service. (No sim card present in the phone). 2. For this, I have taken the SIM card outside OsmocomBB and re-written all SIM API's in osmo-sim-auth (which is the sim card service). 3. This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service. 4, The osmocombb connects to the network and uses this sim card service for authentication etc. 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor. 6. Now, This SIM card service can be used my multiple phones, so now you are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed. 7. My experiments worked well on a LIVE network, understanding the delay in Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this! Look forward to hearing from you! Thanks, Gerard On Mon, Mar 27, 2017 at 2:29 AM, Harald Welte wrote: > Hi Gerard, > > On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote: > > GSM_TAP was the key - Thank you for this help. External CC works well > now. > > great. > > > Just compared mncc with internal and external CC - Debugged a little > > further and realized 1 of the fields of bearer_cap was missing! > > > mncc-python is good - I read your blog. Made some changes (socket path). > > Although it does fail with "Invalid mandatory information" - bearer cap > > missing. I will have to look again at the code. > > Patches are always welcome. I guess mncc-python is so far only used > with OsmoNITB, and not with the MS-side MNCC on OsmocomBB. But it would > be great to have this working, too. > > > Osmo-sim-auth and pysim both same projects right? > > no. osmo-sim-auth just performs a (GSM or UMTS) authentication against > a SIM card. > > pySim is for programming certain cards where that is possible (like > MagicSIM, sysmoSIM, sysmoUSIM, etc.) > > I think there are two distinct purposes and it makes sense to have two > different tools. But yes, it probably could make sense to merge the > code in one repository and simply have multiple executables for that. > > Would you be interested in merging the two, i.e. provide an incremental > patchset against pysim that adds the osmo-sim-auth binary? > > > Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was > > planning to push upstream and then realized there is a project pysim > which > > has all of that ? > > Sorry to hear that. pySim-prog actually existed for much longer time, it > is what we always used to program SIM Cards ever since 2009. > > -- > -- > - Harald Welte > http://laforge.gnumonks.org/ > > > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) >
