spec: Warning the Subscriber If the Pseudonymous IMSI Does Not Change
1 file changed
tree: c716c64c4a0dd4970a04e1b6945f04ff16e60b46
  1. docs/
  2. sim-applet/
  3. .gitignore
  4. README.md
README.md

Osmocom IMSI Pseudonymization Project

Specification and reference SIM applet implementation to conceal the IMSI of a mobile subscriber on the radio interface in a 2G, 3G, 4G network.

Homepage: https://osmocom.org/projects/imsi-pseudo/wiki

How it works

The first pseudo IMSI gets allocated in the HLR, as the SIM card is provisioned. After that pseudo IMSI is used for the first time in location update, the HLR waits for some time, then decides the next pseudo IMSI and sends it together with a delay value as SMS to the SIM. The SIM applet receives the SMS and waits the specified delay. Then it overwrites its current IMSI with the new one, marks the TMSI as invalid, and initiates the next location update. Afterwards, the process repeats.

HLR <-> SIM  LOCATION UPDATE, imsi_pseudo=200
(time passes)
HLR  -> SIM  NEW PSEUDO IMSI, imsi_pseudo=123, delay=60
(time passes until the SMS arrives)
(SIM applet waits 60 seconds)
HLR <-> SIM  LOCATION UPDATE, imsi_pseudo=123
...

In detail

1. Provisioning the SIM

The HLR allocates a new pseudo IMSI as random choice from the pool of available IMSIs. The pseudo IMSI must not be used by any other subscriber as pseudo IMSI, but may be the real IMSI of another subscriber. The subscriber-specific counter imsi_pseudo_i is 0 for the first allocated IMSI for that subscriber.

idimsiimsi_pseudoimsi_pseudo_i
11002000

The pseudo IMSI is saved to the SIM as IMSI, instead of the real IMSI. The SIM is also provisioned with the IMSI pseudonymization applet.

2. Successful Location Update with pseudo IMSI

a) If this was the first Location Update after provisioning the SIM, the subscriber has only one pseudo IMSI allocated. The HLR waits for some time. Then it allocates the next pseudo IMSI from the pool of available IMSIs (as in 1., but with imsi_pseudo_i increased by one). The HLR sends the new pseudo IMSI, the imsi_pseudo_i and a random delay value in one SMS to the SIM.

The random delay is how long the SIM applet should wait before changing the IMSI. This delay prevents easy correlation of the arrival of the SMS with the Location Update that will follow in 3. by the SIM. Due to other latencies in the network, this is a minimum delay. At this point, the subscriber has two allocated pseudo IMSIs:

idimsiimsi_pseudoimsi_pseudo_i
11002000
21001231

b) If this was not the first Location Update after provisioning a new SIM, the subscriber already has two pseudo IMSIs allocated when doing the Location Update. The HLR compares imsi_pseudo_i to find out if the Location Update was done with the newer or older pseudo IMSI.

If the older pseudo IMSI was used, then the SIM applet was not able to set the new IMSI. This may be caused by an SMS arriving late, possibly even months after it was sent in case the UE was without power for a long period of time. Therefore the HLR cannot deallocate the newer pseudo IMSI without risking that the SIM would configure that IMSI and then be locked out (unable to do any further location updates). Instead, the HLR proceeds like in a), but sends the same unused new pseudo IMSI again instead of allocating a new one.

If the newer pseudo IMSI was used, the SIM applet has successfully set the new IMSI. The HLR deallocates the old pseudo IMSI and sends a Purge MS request to the VLR with the old pseudo IMSI. Then the HLR proceeds like in a).

3. Arrival of the SMS

The SIM applet verifies, that imsi_pseudo_i is higher than the last imsi_pseudo_i it has seen (initially: 0). If that is not the case, it discards the message.

The SIM applet registers a timer to wait the specified delay. When the timer expires, the applet updates the last imsi_pseudo_i value that it has seen. Then it overwrites the IMSI with the next pseudo IMSI and invalidates the TMSI and Kc. The applet triggers a refresh, which causes the SIM to do a new Location Update with the new IMSI.

It is important, that the SIM does not invoke the IMSI detach procedure (TS 04.08 Section 4.3.4). This is controlled by the network. Otherwise it becomes trivial to correlate the detach of the old IMSI with the attach or Location Update of the new IMSI.

Notes

What if the SMS gets lost?

Both the old and the new pseudo IMSI entry exist in the HLR.

The SIM will use the old pseudo IMSI in the next Location Update. The HLR will try to send the same new pseudo IMSI with the same new imsi_pseudo_i, as soon as the next Location Update is complete.

What if the SMS arrives late?

The imsi_pseudo_i counter will not be higher than the value the SIM applet already knows. Therefore, the applet will discard the message.

Warning the user if SMS don't arrive

An attacker could possibly block the SMS from arriving at the SIM applet. In that case, the SIM would continue using the old pseudo IMSI indefinitely.

We can count the location updates done with the same pseudo IMSI in the SIM applet, and warn the user if the same pseudo IMSI has been used more than N (e.g. 5) times.

End2end encryption

When deploying the IMSI pseudonymization, the operator should make sure that the pseudo IMSI related SMS between the HLR and the SIM cannot be read or modified by third parties. Otherwise, the next pseudonymous IMSI is leaked, and in case of modifying the IMSI in the SMS, the SIM may be locked out of the network.

OTA SMS are usually encrypted and authenticated (TS 03.48), with algorithms and key lengths that the operator chooses (depending on the SIM and how it is configured).

It was considered to add an additional layer of end2end encryption for the pseudonymized IMSIs on top, but this is out-of-scope for this project. For reference, one could pre-provision a random "imsi_pseudo_key" with the SIM card, store it in the pseudo IMSI table in the HLR, and deploy a new encryption key together with each new pseudo IMSI, attached to the SMS.

User-configurable minimum duration between IMSI changes

It may be desirable to let users configure their minimum duration between IMSI changes. This allows people with a high privacy requirement to switch their pseudonymous IMSI more often, and it allows the IMSI change to happen less often if it is distracting to the user. The latter depends on the phone's software, for example:

  • A Samsung GT-I9100 Galaxy SII smartphone with Android 4.0.3 displays a message at the bottom of the screen for about 5 seconds, but the user interface remains usable.
  • A Samsung GT-E1200 feature phone displays a waiting screen for 16 to 17 seconds and is unusable during that time.