Cellular Network Infrastructure » IMSI Pseudonymization

WIP branch: osmith/imsi-pseudo

Regarding "LU: purge subscriber in VLR": the right GSUP procedure is Location Cancellation (Purge MS would be the opposite direction, VLR instructs HLR to purge MS).

We have unfinished (commented out) code in OsmoHLR to "Cancel in old VLR/SGSN, if new VLR/SGSN differs from old". I will make this work as it was intended (and submit patches to OsmoHLR master, whereas the rest of the IMSI pseudonymization proof of concept will likely just be in a branch).

Then I can extend it to also cancel the subscriber in the old VLR/SGSN if IMSI pseudonymization is enabled, and there is a previous pseudo IMSI allocated, and send the previous pseudo IMSI for cancellation in that case.

osmith wrote:

We have unfinished (commented out) code in OsmoHLR to "Cancel in old VLR/SGSN, if new VLR/SGSN differs from old". I will make this work as it was intended (and submit patches to OsmoHLR master, whereas the rest of the IMSI pseudonymization proof of concept will likely just be in a branch).

This is more effort than I thought, because the existing code, if enabled, would send the Location Cancellation to the peer that does the LU. This happens to be what we need for IMSI pseudonymization, but to fix it in general for OsmoHLR there is more effort involved with sending the Location Cancellation to the old peer. I've documented this in #4491 and will just directly implement it as needed for IMSI pseudonymization.

I'm testing the changes in combination with the SIM applet (and ATT=1 for now).

The HLR successfully detects if the ME is connecting with the new pseudonymous IMSI, and if there is an old pseudonymous IMSI. If that is the case, it sends the Location Cancel Request to the VLR/MSC. However, the VLR/MSC does not necessarily know the subscriber's old pseudo IMSI. In my testing, because I just added it to the DB. But this could also happen if OsmoMSC gets restarted (because its VLR is not persistent).

So for the IMSI pseudonymization branch, I will let OsmoHLR ignore the location cancel errors, by printing a log message and then continuing with Insert Subscriber Data Request as if it was successful.

Furthermore, I've noticed that the HLR needs some more adjustments to translate between real IMSI <> pseudo IMSI during Insert Subscriber Data and probably during more procedures between HLR and MSC. Therefore I'll need to store which of the max. 2 allocated pseudo IMSIs is currently in use (known by the VLR). No, if there are two allocated IMSIs after the location update has started, then the previous pseudo IMSI is in use. Otherwise it would have been deleted.

Code rebased on OsmoHLR master (after the D-GSM merge) and continued with implementation.

It's mostly working well now, the pseudonymous IMSI gets translated to the real IMSI in one place right after receiving GSUP messages, and the pseudonymous IMSI used in the current conversation with the MSC gets saved. When sending GSUP messages to the MSC, the saved pseudo IMSI gets used instead of the real IMSI, also in one place. This appears to be working with all GSUP messages getting sent back and forth between MSC and HLR.

The only missing thing for this issue is sending the Location Cancel Request to the MSC, that is currently failing with:

20200507092814673 DPSEUDO DEBUG subscriber_id='5': used current pseudo IMSI '1236' in LU, deallocating previous: '1235' (lu_fsm.c:115)
20200507092814676 DLGSUP ERROR GSUP 4: MSC-00-00-00-00-00-00: IMSI-1232 OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: Invalid response (rc=1): {Subscriber-Management OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST: imsi="1235" cn_domain=CS} (lu_fsm.c:260)

(real IMSI: 1232, current pseudo IMSI: 1236, previous: 1235)

It's probably easy to figure that out, but I can't look into it more right now.

The code is in this branch: osmith/imsi-pseudo

https://git.osmocom.org/osmo-hlr/log/?h=osmith/imsi-pseudo