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/.
Harald Welte laforge at gnumonks.orgHi 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)