hi Gerard, On Fri, Mar 17, 2017 at 02:47:18AM -0700, Gerard Pinto wrote: Just a quick note: There's mncc-python at http://git.osmocom.org/mncc-python/ which you can use to interface from external programs/scripts, if you'd like. channel (ms 1) It would be best if yo could include GSMTAP protocol traces of such situations, so one can analyze what happens. Also, you can compare the traces of working (no mncc?) and non-working (mncc) cases. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Gerard, On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote: now. great. 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. 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? which 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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Gerard 2017. márc. 28. dátummal, 9:10 időpontban Gerard Pinto < gerardfly9(a)gmail.com&gt; írta: and Tor lately - I would like to hear your views on the same. service. (No sim card present in the phone). all SIM API's in osmo-sim-auth (which is the sim card service). actually know the location of the SIM card service. for authentication etc. which is itself behind Tor. 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. 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

Hi Gerard, On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote: OTA 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. osmo-sim-auth thanks! and all for 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.. which 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. in 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 Welte &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)