OsmocomBB MNCC socket implementation without LCR

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.com
Wed Mar 29 09:07:11 UTC 2017

Hi 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!

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
> > 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>

More information about the baseband-devel mailing list