<div dir="ltr"><div><div><div><div><div><div><div>Hi Herald,<br><br></div>Thanks for the in-depth view.<br></div>Something that I missed out and you mentioned - IMEI randomization (I haven't done this)<br></div>And also for introducing me to SIMtrace.<br></div>As soon as I am done with this one, I will look into pysim and SIMtrace.<br><br></div>Herald, I wish you good luck for OsmoCon2017 good success. <br>I wish to attend it someday, I look forward to hear about the session on 2.5G services and Fundamental GSM radio frequency planning.<br><br></div>Thanks for the help so far!<br></div>Gerard.<br><div><div><br><br><div><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 2:45 AM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gerard,<br>
<span class=""><br>
On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote:<br>
> 1) Have you or your team tried to reverse engineer/hacking Over the Air OTA<br>
> spec - firmware upgrade (understanding this type of communication) using<br>
> OpenNITB and latest phones where bootloaders are locked?<br>
<br>
</span>I haven't looked at this personally, but several people have looked at<br>
security of several different OTA updates for about a decade by now.<br>
The main issue is that there is no standard protocol or system, and<br>
everyone cooks up their own.<br>
<span class=""><br>
> - I was planning to try this! But now I will take up merging osmo-sim-auth<br>
> and py-sim. (I'm not a great dev but I'm passionate about osmocom and<br>
> willing to contribute my time to learning/contributing the same).<br>
<br>
</span>thanks!<br>
<span class=""><br>
> 2) I have been trying something different with OsmocomBB, osmo-sim-auth and<br>
> Tor lately - I would like to hear your views on the same.<br>
>  Attack Model: Geo-Location Anonymous calling in GSM.<br>
><br>
> Description:<br>
> 1. The attacker uses OsmocomBB phone to make a call using a sim card<br>
> service. (No sim card present in the phone).<br>
> 2. For this, I have taken the SIM card outside OsmocomBB and re-written all<br>
> SIM API's in osmo-sim-auth (which is the sim card service).<br>
> 3. This sim card service is deployed over Tor network, so no one can<br>
> actually know the location of the SIM card service.<br>
> 4, The osmocombb connects to the network and uses this sim card service for<br>
> authentication etc.<br>
> 5. The whole setup of calling etc is initiated by the sim card service,<br>
> which is itself behind Tor.<br>
<br>
</span>This is basically the sim card forwarding / remote SIM, which people<br>
have been experimenting on SIMtrace for quite some time.  In this case<br>
you can use any regular phone or modem, and don't need osmocombb.  There<br>
is a complete 'remote sim / card emulation' proof of concept in the<br>
simtrace2.git repository, but this requires a prototype of the simtrace<br>
2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware<br>
(with SAM7).<br>
<br>
Also, there are plenty of commercial suppliers of systems like you have<br>
described.<br>
<br>
a) in the area of automatic roaming testing (between operators)<br>
b) in the area of automatic service quality testing (between operators)<br>
c) in the grey area of so-called SIM-boxes, where you have hundreds to<br>
   thousands of SIM cards in one data center, which you can remotely<br>
   provision to any number of "GSM VoIP gateways" spread in different<br>
   countries.  This is typically used for interconnection fraud by shady<br>
   operators.<br>
<br>
None of the above use Tor (as they have different use cases), but the<br>
option 'c' at least also uses IMEI randomization to avoid tracking the<br>
subscriber via his IMEI, which presumably you would want to do in your<br>
OsmocomBB based system, t..<br>
<span class=""><br>
> 6. Now, This SIM card service can be used my multiple phones, so now you<br>
> are not exactly going to track the phone since if I use the SIM card<br>
> service to another phone (cell area) the DB entry in VLR has changed which<br>
> says the location has changed.<br>
<br>
</span>Yes, but you have to be very quick.  Of course from the time of the LU<br>
throughout the call, your position is known to the observer.  Not<br>
because of your IMSI or IMEI (which you both keep changing) but because<br>
of the phone numbers you call.<br>
<br>
It depends on what you want to defend against.  Basically you can do<br>
this already if you carry around a huge bag of sim cards which you<br>
always only use for a single call, *and* you have a phone that can<br>
change the IMEI every time you change the SIM.  This is apparently what<br>
e.g. human rights activists in hostile countries are doing.<br>
<br>
However, the biggest problem in such situations is not your own<br>
identity, but the identities you contact.  So if you keep calling the<br>
same destination number, all of the above is useless as the key to find<br>
you is by the destination number.  So at the same time, you require a<br>
potentially large number of phone numbers that are not in some way<br>
associated to another (and at best in different countries), which then<br>
provide call redirect to your real destination.<br>
<span class=""><br>
> 7. My experiments worked well on a LIVE network, understanding the delay in<br>
> Tor the network, still, the BTS was accepting RES response challenge from<br>
> the SIM card service behind Tor - I still have to calculate the exact max<br>
> acceptable delay in sending RES back to BTS to confirm this!<br>
<br>
</span>I think I remember that at least 2 if not 4 seconds of delay are<br>
acceptable for the complete authentication handshake.  People are even<br>
doing this over satellite back-haul.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
==============================<wbr>==============================<wbr>================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br></div>