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/baseband-devel@lists.osmocom.org/.
Gerard Pinto gerardfly9 at gmail.comHi Herald, Thanks for the in-depth view. Something that I missed out and you mentioned - IMEI randomization (I haven't done this) And also for introducing me to SIMtrace. As soon as I am done with this one, I will look into pysim and SIMtrace. Herald, I wish you good luck for OsmoCon2017 good success. I wish to attend it someday, I look forward to hear about the session on 2.5G services and Fundamental GSM radio frequency planning. Thanks for the help so far! Gerard. On Tue, Mar 28, 2017 at 2:45 AM, Harald Welte <laforge at gnumonks.org> wrote: > 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 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 -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170329/c3d4c94b/attachment.htm>