Cellular Network Infrastructure » IMSI Pseudonymization

laforge pointed out, that we can just look at SI/LU accept of widespread networks:

Wouldn't it simply be a test to register to the
three German networks with a respective operator SIM card and check if switching the
phone off caues an IMSI DETACH? Or, actually, it would probably be sufficient to look
at the SI (or the LU ACCEPT?) where the network indicates if IMSI DETACH procedure shall
be used or not. Any of the above should be possible with OsmocomBB.

If there is a switch to tell the MS to do silent IMSI Detach, then it should be sufficient to set it.
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.
laforge Am I missing something?

Ah, I did find that, but interpreted it differently:

ATT, Attach-detach allowed (octet 2)
Bit
7
0 MSs in the cell are not allowed to apply IMSI attach and detach procedure.
1 MSs in the cell shall apply IMSI attach and detach procedure.

It sounds like it completely disallows attaching to the cell, I thought maybe it's for some kind of handover contingency cell,
i.e. not allowing "Location Update (IMSI Attach)" in the first place. Giving it a try...

Next question is whether a similar flag exists for UTRAN
(for us in particular, we probably need to look at femto cells' dmi config)

I just tested setting ATT=0 in SI3 Channel Description via

osmo-bsc.cfg

network
 bts N
  channel-description attach 0

With ATT=0, indeed the IMSI Detach Indication is omitted, but the phone also does not send Location Updating (IMSI Attach) either, anymore.

• 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.
  In the case of OsmoMSC, we would also not Page for this subscriber.
• When the phone first requests anything, e.g. *#100#, it gets rejected by the MSC (CM Service Reject, cause "IMSI unknown in VLR").
• The phone then does a Location Updating (Type "Normal").
• After that, a CM Service is accepted and Paging would happen.

So, we not only lose IMSI Detach, but also IMSI Attach, as the specs indicate.

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.
I wonder whether a phone that moves to a different cell still does a Location Updating? Probably yes?
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.

• implicitly does an Update Location procedure towards the HLR as soon as a CM Service Request arrives?
• always Pages MSISDNs even if they are not attached?

So ... we can switch off IMSI Attach+Detach and run a Proof-of-Concept that a SIM can change its IMSI.
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.
Otherwise we could enable OsmoMSC to implicitly attach subscribers and always Page everyone, somehow.

Todo:

• ATT=0 on UTRAN?
• How does a SIM/baseband behave when its IMSI is changed?

With ATT=0, LU (Periodic) still happen as usual.

How does a SIM/baseband behave when its IMSI is changed?

Let's add a menu entry that changes the IMSI to check this: #4412

How does a SIM/baseband behave when its IMSI is changed?

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

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.

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.

ATT=0 on UTRAN?

I've spent some time on researching this, but could not a spec reference like it was found for GERAN. Maybe laforge knows this without looking it up, or can provide a pointer to where to look?

osmith wrote:

How does a SIM/baseband behave when its IMSI is changed?

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

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

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

Neels wrote:

• When the phone first requests anything, e.g. *#100#, it gets rejected by the MSC (CM Service Reject, cause "IMSI unknown in VLR").
• The phone then does a Location Updating (Type "Normal").
• After that, a CM Service is accepted and Paging would happen.

I was able to reproduce this (using ATT=0).

laforge will send us OsmocomBB phones to test for ATT=0 in German real-world networks.