https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-02-17T10:29:59ZOpen Source Mobile CommunicationsIMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174732020-02-17T10:29:59Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-2 priority-default closed" href="/issues/4398">Feature #4398</a>: Approach B: Calculate pseudo IMSI with HOTP</i> added</li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174752020-02-17T10:30:10Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-2 priority-default closed" href="/issues/4397">Feature #4397</a>: Approach A: Calculate pseudo IMSI with TOTP</i> added</li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174762020-02-17T11:36:42Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174772020-02-17T13:49:51Zosmith
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17477/diff?detail_id=28930">diff</a>)</li></ul><p><a class="user active" href="https://osmocom.org/users/91">neels</a> gave feedback: NEW SESSION REQ and NEW SESSION RESP can be removed, if we let the HLR suggest the same pseudo IMSI that was already allocated, until the SIM accepts it.</p>
<p>Text updated.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174782020-02-18T07:55:48Zosmith
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17478/diff?detail_id=28932">diff</a>)</li></ul><p><a class="user active" href="https://osmocom.org/users/7">laforge</a> gave feedback about the scope of the project. Text updated: additional encryption layer removed from the protocol description and placed in the "End2end encryption" section as note.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174812020-02-18T08:17:56Zosmith
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17481/diff?detail_id=28938">diff</a>)</li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174832020-02-18T14:38:50Zosmith
<ul></ul><p>I've created a README.md for imsi-pseudo.git based on the description of this issue:</p>
<p><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo">https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo</a></p>
<p>(Seems like it is not yet synced to git.osmocom.org?)</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174842020-02-18T14:41:16Zosmith
<ul><li><strong>Assignee</strong> set to <i>osmith</i></li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174852020-02-18T14:54:28Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Discussion: when to change the pseudo IMSI?</p>
<p>Changing the pseudo IMSI is only possible when the subscriber is attached and can send and receive SMS.<br />It is always the HLR that decides when to change the IMSI.</p>
<p>Some options:</p>
<ul>
<li>upon each (periodic) Location Updating</li>
<li>upon each Complete Layer 3</li>
<li>timer based</li>
</ul>
<p>One might think that we need to sanitize and separate IMSI changes from other service requests, but<br />once a conn to the subscriber is established (Complete Layer 3), the IMSI can be changed at any time without affecting that particular connection.</p>
<p>For example, at first I thought we need to make sure to not mix normal SMS with those that change the IMSI,<br />but it is perfectly fine to negotiate a new IMSI mixed with other activity.<br />The new IMSI should only come into effect upon the next Complete Layer 3.</p>
<p>A problem can still occur when the SIM card changes the IMSI and the ACK is not sent in the same conn:</p>
<pre>
SIM ---Complete-Layer-3--> MSC
SIM <---------------NEW-IMSI------ HLR
SIM <--Clear-------------> MSC
(SIM uses new IMSI)
SIM ---Complete-Layer-3--> MSC
SIM ----------------NEW-IMSI-ACK-> HLR
</pre>
<p>A realistic scenario for this would be: A Location Updating is carried out by the MSC.<br />The HLR reacts quickly to send the NEW-IMSI SMS, received in the same connection as the LU.<br />After that, the MSC Clears the conn, since no more transactions are pending.<br />The SIM still needs to send the NEW-IMSI ACK, hence opens a new conn (CM Service Request to send the SMS).</p>
<p>The question is: which IMSI should be used now?<br />Should the SIM re-attach with the new IMSI, and only then send the ACK for the new IMSI?</p>
<p>One possibility would be that the SIM remains on the old IMSI until the SMS to ACK it has been sent and RP-ACKed by the MSC.<br />Yet, neither MSC nor SIM can ever be sure that the ACK SMS has actually arrived at the HLR managing the IMSIs.</p>
<p>Probably the simplest solution is to make the HLR accept both old and new IMSIs while in transition.<br />But is it then really necessary to send a NEW-IMSI-ACK? The SIM has already ACKed the new IMSI by using it to attach to the MSC.</p>
<p>Another part in this puzzle is the MSC's state.<br />An MSC considers an IMSI attached only when a Location Updating has occured.<br />If a SIM changes its IMSI and sends another CM Service Request, the MSC would reject this IMSI, which it does not know.</p>
<p>In Osmocom, we could teach the HLR to tell the MSC about a changed IMSI. But one goal of this project is to not modify network components other than HLR and SIM.</p>
<p>So, a SIM that has changed its IMSI must always do a Location Updating for IMSI Attach first thing after changing its IMSI.</p>
<p>This leads me to this flow:</p>
<pre>
MSC <--SMS-NEW-IMSI--- HLR
SIM <-----Paging-------- MSC
SIM ---Pag.Resp--------> MSC
SIM <--SMS-NEW-IMSI----- MSC
SIM <--Clear-----------> MSC
SIM ---IMSI-Detach-----> MSC
SIM ---LU-IMSI-Attach--> MSC
MSC ---Update-Location--> HLR
(= implicit NEW IMSI ACK)
</pre> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174862020-02-18T15:11:42Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>also consider TMSIs: when changing the IMSI, the SIM should discard its TMSI used for the network.<br />The MSC still associates that TMSI with the previous IMSI.<br />Hence, each LU-IMSI-Attach after a new IMSI must send the new IMSI in clear, over the unencrypted air interface.</p>
<p>A person maliciously surveilling the network would see this IMSI in clear. It would be an IMSI Attach of an unknown random IMSI.<br />However, it would probably be possible to time-correlate it to a previous IMSI-Detach.</p>
<p>Hence, to actually be able to preserve privacy, the SIM should not immediately change the IMSI upon receiving an SMS with NEW-IMSI.<br />What if a random timer in the SIM causes the IMSI change some minutes after receiving the new IMSI?<br />This doesn't help, the correlation is done between the IMSI Detach (probably using the previous TMSI) and the new IMSI Attach.</p>
<p>Maybe the SIM applet can somehow cause the IMSI Detach to be skipped.<br />Once a Location Updating with the new IMSI happens, the HLR could tell the MSC to purge the previous IMSI, with no visibility on the air interface.<br />(This is important to avoid having two IMSIs with the same MSISDN in the MSC)</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174872020-02-18T16:33:41Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Summary of important aspects so far:</p>
<ul>
<li>IMSI pool managed in HLR; HLR tells SIM when to move to a new IMSI.
<ul>
<li>When the HLR sends an SMS to the SIM, it can never be sure how soon the SMS arrives / how soon the new IMSI is first used.<br /> Hence the HLR must "park" a newly allocated IMSI alongside an old IMSI up until the new IMSI is actually used.</li>
<li>HLR can "never" invalidate a parked new IMSI.<br /> The SIM has no fallback to a previous IMSI, so if a new IMSI has been dealt out to a SIM, the HLR must accept it however distant in the future.<br /> (Say, the applet changed the IMSI in the SIM, but then the phone goes out of power for months, the HLR must still accept the new IMSI,<br /> or the SIM is locked out and needs to be re-provisioned.)
<ul>
<li>Todo: consider a fallback mechanism in the SIM to be able to free unused new IMSIs in the HLR?</li>
</ul>
</li>
<li>In the worst case, all NEW-IMSI Requests are dropped, and every subscriber occupies two IMSIs</li>
<li>HLR should re-send "parked" new IMSIs regularly</li>
<li>The HLR can decide to allocate less new IMSIs as the IMSI pool depletes</li>
</ul></li>
</ul>
<ul>
<li>MSC functionality remains unchanged, hence
<ul>
<li>The previous IMSI must be detached or invalidated in the VLR to avoid duplicate MSISDN</li>
<li>A new IMSI must always attach to the MSC with Location Updating (IMSI Attach)
<ul>
<li>We need no NEW-IMSI-ACK SMS from the SIM to the HLR, the mandatory LU for IMSI Attach already serves the purpose of ACKing the new IMSI.</li>
</ul>
</li>
<li>The SIM must drop its TMSI when it changes its IMSI (MSC associates the TMSI to the old IMSI)</li>
</ul></li>
</ul>
<ul>
<li>The goal is privacy, hence it should be hard to follow IMSI changes: avoid time correlation between old and new IMSI.<br /> The longer the delay between events of old and new IMSI, the more subscribers change their IMSIs concurrently,<br /> the harder it is to follow one particular IMSI.
<ul>
<li>Insert a delay between the NEW-IMSI Request and the actual time that the SIM changes to the new IMSI.<br /> (avoid correlating SMS of an old IMSI/TMSI to the new IMSI attach)
<ul>
<li>The delay affects how long a subscriber keeps two IMSIs allocated in parallel,<br /> so the HLR should probably tell the SIM about the amount of delay in the NEW-IMSI-Request message<br /> (i.e. make this configurable without SIM modification).</li>
<li>The delay will never be precise, since the SMSC may introduce arbitrary delay for random reasons.<br /> (optional todo: maybe the SMS transaction conveys to the SIM how long delivery has taken?)</li>
</ul>
</li>
<li>The phone can detach (IMSI-Detach old IMSI or TMSI) and then attach (LU with new IMSI) in short succession,<br /> but this would be pretty obvious for attackers to correlate old TMSI/IMSI with new IMSI.</li>
<li>It is important to keep the subscriber attached with (almost) no interruption in service.<br /> So it is not an option to IMSI-Detach, then wait some random time period, and only attach later.<br /> There must be ideally no delay of "moving" the MSISDN from the old IMSI to the new IMSI in the VLR.
<ul>
<li>Omit the MS ---IMSI-Detach--> MSC (TODO: is this possible from SIM applet?)</li>
<li>Invalidate the MSC's state for the old IMSI from the HLR: as soon as the new IMSI shows up in an Update Location, do:
<ul>
<li>option: send a Purge MS of the old IMSI from the HLR to the MSC?</li>
<li>option: send an Insert Subscriber Data for the old IMSI with an invalid MSISDN?</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
<p>The usefulness of the project seems to pivot on the visibility of the IMSI Detach.<br />If we can't omit the IMSI Detach message, then we either introduce an interruption in network service,<br />or we make it easy to correlate old and new IMSIs by time correlation of Detach and Attach.<br />A likely conclusion is that we also need to modify the MSC to play along in the IMSI swap<br />with custom messages from the HLR to reach effective obfuscation of subscriber identity.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174882020-02-18T16:44:22Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Open question: how to interface HLR and SMS service</p>
<ul>
<li>SMS-over-GSUP?</li>
<li>SMPP handler and CTRL interface to osmo-hlr?</li>
</ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174892020-02-18T17:31:13Zlaforge
<ul></ul><p>On Tue, Feb 18, 2020 at 04:33:42PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<ul>
<li>IMSI pool managed in HLR; HLR tells SIM when to move to a new IMSI.</li>
</ul>
</blockquote>
<p>One disadvantage of such an "explicit" mechanism relying on OTA SMS is that any<br />intermediary / adversary can just block those SMS and thereby render the entire<br />mechanism unusable. A mechanism that allowed the SIM to autonomously switch to<br />a different IMSI would be more robust against that kind of attack, but then of course<br />has other disadvantages.</p>
<blockquote>
<ul>
<li>MSC functionality remains unchanged, hence
<ul>
<li>The previous IMSI must be detached or invalidated in the VLR to avoid duplicate MSISDN</li>
</ul></li>
</ul>
</blockquote>
<p>This can be done explicitly by the HLR sending a (IIRC) CancelLocation or PurgeMS request. for the old IMSI.</p>
<p>This is what would normally happen if the IMSI e.g. meanwhile registered at another MNO (after<br />jumping from one country to another), and the HLR would then inform the old VLR/MSC that the<br />ISMI is gone.</p>
<p>This way we can make sure no "same MSISDN at two IMSIs" and related unspecified behavior occurs<br />in the VLR/MSC.</p>
<blockquote>
<p>The usefulness of the project seems to pivot on the visibility of the IMSI Detach.<br />If we can't omit the IMSI Detach message, then we either introduce an interruption in network service,<br />or we make it easy to correlate old and new IMSIs by time correlation of Detach and Attach.</p>
</blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174902020-02-18T20:11:24Zlaforge
<ul></ul><p>On Tue, Feb 18, 2020 at 04:44:23PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<ul>
<li>SMS-over-GSUP?</li>
</ul>
</blockquote>
<p>no, that would mean you need an external SMSC first. It's like MNCC: Either you<br />use the internal, or all related handling is external.</p>
<blockquote>
<ul>
<li>SMPP handler and CTRL interface to osmo-hlr?</li>
</ul>
</blockquote>
<p>SMPP certainly is the way to go. And yes, if it was external to osmo-hlr, it would<br />be best. We preferably don't want to burden the normal osmo-hlr code with all related<br />complexities of this research project.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174932020-02-19T10:35:23Zosmith
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>One disadvantage of such an "explicit" mechanism relying on OTA SMS is that any<br />intermediary / adversary can just block those SMS and thereby render the entire<br />mechanism unusable. A mechanism that allowed the SIM to autonomously switch to<br />a different IMSI would be more robust against that kind of attack, but then of course<br />has other disadvantages.</p>
</blockquote>
<p>Indeed. <a class="user active" href="https://osmocom.org/users/7">laforge</a>, what do you think about warning the user from the SIM applet, if the pseudo IMSI does not change?<br />Elaborated here: <a class="external" href="https://osmocom.org/issues/4400#Warning-the-user-if-SMS-dont-arrive">https://osmocom.org/issues/4400#Warning-the-user-if-SMS-dont-arrive</a></p>
<blockquote><blockquote>
<p>The usefulness of the project seems to pivot on the visibility of the IMSI Detach.<br />If we can't omit the IMSI Detach message, then we either introduce an interruption in network service,<br />or we make it easy to correlate old and new IMSIs by time correlation of Detach and Attach.</p>
</blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p>
</blockquote>
<p>Created new issue <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Research: Make sure that we can silently detach the IMSI (Stalled)" href="https://osmocom.org/issues/4404">#4404</a> for doing a proof of concept for silent IMSI detach.</p>
<p>neels wrote:</p>
<blockquote>
<p>Open question: how to interface HLR and SMS service</p>
</blockquote>
<p>Created new issue <a class="issue tracker-2 status-4 priority-2 priority-default" title="Feature: OsmoHLR: How to interface with SMS service? (Feedback)" href="https://osmocom.org/issues/4403">#4403</a> for that discussion, please follow up there.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174962020-02-19T11:11:04Zlaforge
<ul></ul><p>On Wed, Feb 19, 2020 at 10:35:24AM +0000, <a class="email" href="mailto:redmine@lists.osmocom.org">redmine@lists.osmocom.org</a> wrote:</p>
<blockquote>
<p>what do you think about warning the user from the SIM applet, if the pseudo IMSI does not change?</p>
</blockquote>
<p>yes, makes a lot of sense. good idea.</p>
<blockquote><blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p>
</blockquote>
<p>Created new issue <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Research: Make sure that we can silently detach the IMSI (Stalled)" href="https://osmocom.org/issues/4404">#4404</a> for doing a proof of concept for silent IMSI detach.</p>
</blockquote>
<p>what do you mean by proof-of-concept? 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> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=174972020-02-19T12:50:47Zosmith
<ul></ul><p>laforge wrote:</p>
<blockquote><blockquote><blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p>
</blockquote>
<p>Created new issue <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Research: Make sure that we can silently detach the IMSI (Stalled)" href="https://osmocom.org/issues/4404">#4404</a> for doing a proof of concept for silent IMSI detach.</p>
</blockquote>
<p>what do you mean by proof-of-concept? 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>
<p>Oh I did not realize that it can be done that way, especially that it's encoded in the SI / LU Accept. I'll update that issue.</p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=175192020-02-21T14:35:03Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4401">Feature #4401</a>: Proof of concept for counting Location Updates in SIM applet</i> added</li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=175212020-02-21T14:35:24Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/4404">Feature #4404</a>: Research: Make sure that we can silently detach the IMSI</i> added</li></ul> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=175482020-02-26T15:06:02Zosmith
<ul></ul><p>Updated the README, that describes the whole process, with all the feedback above:</p>
<p><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo/+/refs/heads/master/README.md">https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo/+/refs/heads/master/README.md</a></p> IMSI Pseudonymization - Feature #4400: Approach C: HLR decides and sends the entire next pseudo IMSI to SIMhttps://osmocom.org/issues/4400?journal_id=178752020-03-27T12:43:10Zosmith
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>This is the approach we will describe in our spec and implement. Closing.</p>