https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-02-19T10:46:46ZOpen Source Mobile CommunicationsIMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=174952020-02-19T10:46:46Zosmith
<ul></ul> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=174982020-02-19T12:55:12Zosmith
<ul><li><strong>Subject</strong> changed from <i>Proof of concept for silent IMSI detach</i> to <i>Make sure that we can silently detach the IMSI</i></li></ul><p>laforge <a href="https://osmocom.org/issues/4400?issue_count=5&issue_position=5&prev_issue_id=4401#note-16" class="external">pointed out</a>, that we can just look at SI/LU accept of widespread networks:</p>
<blockquote>
<p>Wouldn't it simply be a test to register to the<br />three German networks with a respective operator SIM card and check if switching the<br />phone off caues an IMSI DETACH? Or, actually, it would probably be sufficient to look<br />at the SI (or the LU ACCEPT?) where the network indicates if IMSI DETACH procedure shall<br />be used or not. Any of the above should be possible with OsmocomBB.</p>
</blockquote> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=174992020-02-19T14:32:01Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>If there is a switch to tell the MS to do silent IMSI Detach, then it should be sufficient to set it.<br />Spent some time looking, but couldn't find any such SI switch in TS 44.018, nor in the LU messages in TS 24.008.<br /><a class="user active" href="https://osmocom.org/users/7">laforge</a> Am I missing something?</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175002020-02-19T18:21:17Zlaforge
<ul></ul><p>On Wed, Feb 19, 2020 at 02:32:02PM +0000, <a class="email" href="mailto:redmine@lists.osmocom.org">redmine@lists.osmocom.org</a> wrote:</p>
<blockquote>
<p>If there is a switch to tell the MS to do silent IMSI Detach, then it should be sufficient to set it.</p>
</blockquote>
<p>It is rather to the contrary: The network tells the MS whether it should perform IMSI DETACH or not. So the flag <strong>enables</strong> it.</p>
<pre>
TS 04.08 Section 4.3.4 IMSI detach procedure
The IMSI detach procedure may be invoked by a mobile station if the
mobile station is deactivated or if the Subscriber Identity Module (see
3GPP TS 02.17) is detached from the mobile station. A flag (ATT)
broadcast in the SYSTEM INFORMATION TYPE 3 message on the BCCH is used
by the network to indicate whether the detach procedure is required.
</pre>
<p>We've had support for setting this flag via the vty since openbsc commit<br />2ee7ecddeb423dd8b2be984be58c5aee3b359a2f in 2012:</p>
<p>channel-description attach</p>
<p>The naming is a bit weird, and I think the help/reference may be<br />outright wrong.</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175062020-02-20T13:55:24Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Ah, I did find that, but interpreted it differently:</p>
<pre><code>ATT, Attach-detach allowed (octet 2)<br />Bit<br />7<br />0 MSs in the cell are not allowed to apply IMSI attach and detach procedure.<br />1 MSs in the cell shall apply IMSI attach and detach procedure.</code></pre>
<p>It sounds like it completely disallows attaching to the cell, I thought maybe it's for some kind of handover contingency cell,<br />i.e. not allowing "Location Update (IMSI Attach)" in the first place. Giving it a try...</p>
<p>Next question is whether a similar flag exists for UTRAN<br />(for us in particular, we probably need to look at femto cells' dmi config)</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175112020-02-20T16:10:39Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> <a href="/attachments/4030">trace_filtered.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4030/trace_filtered.pcapng">trace_filtered.pcapng</a> added</li></ul><p>I just tested setting ATT=0 in SI3 Channel Description via</p>
<p>osmo-bsc.cfg<br /><pre>
network
bts N
channel-description attach 0
</pre></p>
<p>With ATT=0, indeed the IMSI Detach Indication is omitted, but the phone also does not send Location Updating (IMSI Attach) either, anymore.</p>
<ul>
<li>So, a phone that is switched on does only scan for a PLMN it already knows, shows to the user that it is attached, but never registers. The network has no clue that the phone is available.<br /> In the case of OsmoMSC, we would also not Page for this subscriber.</li>
<li>When the phone first requests anything, e.g. *#100#, it gets rejected by the MSC (CM Service Reject, cause "IMSI unknown in VLR").</li>
<li>The phone then does a Location Updating (Type "Normal").</li>
<li>After that, a CM Service is accepted and Paging would happen.</li>
</ul>
<p>So, we not only lose IMSI Detach, but also IMSI Attach, as the specs indicate.</p>
<p>It seems that a SIM that modifies its IMSI must then initiate some sort of CM Service Request so that it gets attached to the MSC.<br />I wonder whether a phone that moves to a different cell still does a Location Updating? Probably yes?<br />Then, maybe maybe, if a base band gets a new IMSI, does it consider being moved to a new cell and sends a Location Updating? We need to test.</p>
I wonder how commercial networks solve this, given they have ATT=0 set. Do they always consider all of their IMSIs attached at the last seen MSC?<br />Probably an MSC (that has lost its VLR state)
<ul>
<li>implicitly does an Update Location procedure towards the HLR as soon as a CM Service Request arrives?</li>
<li>always Pages MSISDNs even if they are not attached?</li>
</ul>
<p>So ... we can switch off IMSI Attach+Detach and run a Proof-of-Concept that a SIM can change its IMSI.<br />Then, to not remain unreachable after an IMSI change, the SIM could run an arbitrary CM Service Request towards the CN to enforce a LU.<br />Otherwise we could enable OsmoMSC to implicitly attach subscribers and always Page everyone, somehow.</p>
<p>Todo:</p>
<ul>
<li>ATT=0 on UTRAN?</li>
<li>How does a SIM/baseband behave when its IMSI is changed?</li>
</ul> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175122020-02-20T16:22:49Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>With ATT=0, LU (Periodic) still happen as usual.</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175222020-02-21T14:35:24Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4400">Feature #4400</a>: Approach C: HLR decides and sends the entire next pseudo IMSI to SIM</i> added</li></ul> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=175232020-02-21T14:48:59Zosmith
<ul></ul><blockquote>
<p>How does a SIM/baseband behave when its IMSI is changed?</p>
</blockquote>
<p>Let's add a menu entry that changes the IMSI to check this: <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: SIM applet: add debug menu entry to change IMSI (Resolved)" href="https://osmocom.org/issues/4412">#4412</a></p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=178762020-03-27T16:07:55Zosmith
<ul></ul><blockquote>
<p>How does a SIM/baseband behave when its IMSI is changed?</p>
</blockquote>
<p>When I checked last month on a feature phone, changing the IMSI would display a waiting screen for ~10 seconds (saying something like the SIM is being updated). I wanted to reproduce it now, measure the time and analyze a bit more how it behaves in wireshark, also reproduce what Neels wrote about ATT=0. But for some reason MS did not attach to the BTS at all, I'll debug this next week...</p>
<p>Neels also told me last month, that on a smart phone there would be an indicator for around the same length of time, that says that the SIM is being updated.</p>
<p>Anyhow, the waiting delay is not great for a usability perspective. But if we only change the IMSI rarely, say every hour or every few hours, it seems like a good trade-off between increased privacy due to IMSI pseudonymization and a little decreased usability.</p>
<blockquote>
<p>ATT=0 on UTRAN?</p>
</blockquote>
<p>I've spent some time on researching this, but could not a spec reference like it was found for GERAN. Maybe <a class="user active" href="https://osmocom.org/users/7">laforge</a> knows this without looking it up, or can provide a pointer to where to look?</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=178772020-03-27T16:08:20Zosmith
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=179112020-03-31T10:32:00Zosmith
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>70</i></li></ul><p>osmith wrote:</p>
<blockquote><blockquote>
<p>How does a SIM/baseband behave when its IMSI is changed?</p>
</blockquote>
<p>When I checked last month on a feature phone, changing the IMSI would display a waiting screen for ~10 seconds (saying something like the SIM is being updated). I wanted to reproduce it now, measure the time and analyze a bit more how it behaves in wireshark, also reproduce what Neels wrote about ATT=0. But for some reason MS did not attach to the BTS at all, I'll debug this next week...</p>
</blockquote>
<p>After inserting the SIM with the SIM applet into a smartphone, it also would not register at first. But after waiting a few minutes, it worked again and now the SIM is working normally in both phones (smartphone and feature phone).</p>
<p>The feature phone displays a waiting screen for 16 to 17 seconds (!) (measured three times with a stop clock), during which the phone can not be used. The smartphone only for ~5 seconds and the UI is not blocked (-> definitively less annoying). For real world usage, it would probably be useful to let the user configure the desired minimum rate at which a new pseudo IMSI should be provisioned. People with smartphones where it is not so annoying could set it to a higher rate than people with a feature phone that becomes unusable as the IMSI changes, and people with a high requirement for privacy could set it to a high rate too (no matter which hardware they use). I have added a related note to the <a href="https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo/+/refs/heads/master/README.md#user_configurable-minimum-duration-between-imsi-changes" class="external">README</a>.</p>
<p>Neels wrote:</p>
<blockquote>
<ul>
<li>When the phone first requests anything, e.g. *#100#, it gets rejected by the MSC (CM Service Reject, cause "IMSI unknown in VLR").</li>
<li>The phone then does a Location Updating (Type "Normal").</li>
<li>After that, a CM Service is accepted and Paging would happen.</li>
</ul>
</blockquote>
<p>I was able to reproduce this (using ATT=0).</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=179142020-04-01T07:31:37Zosmith
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p><a class="user active" href="https://osmocom.org/users/7">laforge</a> will send us OsmocomBB phones to test for ATT=0 in German real-world networks.</p> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=179262020-04-01T08:29:20Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-2 priority-default" href="/issues/4480">Bug #4480</a>: Applet/OsmoMSC: fix or workaround for OsmoMSC only paging attached MS</i> added</li></ul> IMSI Pseudonymization - Feature #4404: Research: Make sure that we can silently detach the IMSIhttps://osmocom.org/issues/4404?journal_id=179942020-04-15T10:06:58Zosmith
<ul><li><strong>Subject</strong> changed from <i>Make sure that we can silently detach the IMSI</i> to <i>Research: Make sure that we can silently detach the IMSI</i></li></ul>