Cellular Network Infrastructure » IMSI Pseudonymization

= Specification for IMSI Pseudonymization on the Radio Interface for 2G and Above

== Introduction

=== Protecting the IMSI on the Radio Interface is Desirable

A long-standing issue in the 3GPP specifications is, that mobile phones and

other mobile equipment (ME) have to send the International Mobile Subscriber

Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the

person who bought the associated Subscriber Identity Module (SIM) used in the

ME. Therefore most people can be uniquely identified by recording the IMSI that

their ME is sending. Efforts are made in the 2G and above specifications to

send the IMSI less often, by using the Temporary Mobile Subscriber Identity

(TMSI) where possible.

But this is not enough. So-called IMSI catchers were invented and are used to

not only record IMSIs when they have to be sent. But also to force ME to send

their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have

become small and affordable, even criminals actors without much budget can use

them to track anybody with a mobile phone.

=== Summary of Proposed Solution

The solution presented in this document is to periodically change the IMSI of

the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR)

or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM

via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the

SIM with the new value. The only component that needs to be changed in the

network besides the SIM is the HLR/HSS, therefore it should be possible even

for a Mobile Virtual Network Operator (MVNO) to deploy this privacy

enhancement.

=== Summary of Existing Location Updating Procedures in RAN and CN

The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a

subscriber, after the subscriber was added with the same data to the HLR/HSS.

In the Remote Access Network (RAN), the IMSI is sent over the air interface and

then transmitted to the Core Network (CN), where it is validated by the

HLR/HSS. The involved components vary by the generation of the network and

whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)

connection, but the principle is the same. This document uses 2G CS Location

Updating for reference, as in <<figure-imsi-regular>>.

The IMSI is transmitted in the Location Updating Request from ME. The VLR

needs an authentication challenge specific to the secret keys on the SIM to

authenticate the SIM, and looks the authentication challenges up by the IMSI.

If the VLR does not have any more authentication challenges for the IMSI (as it

happens when the VLR sees the IMSI for the first time), the VLR requests new

authentication challenges from the HLR. Then the HLR verifies that the IMSI is

known and, if it is unknown, sends back an error that will terminate the

Location Updating procedure.

After the VLR found the authentication challenge, it authenticates the SIM, and

performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR

has the required information to finish the Location Updating, and continues

with an Update Location Request procedure with the HLR. Afterwards, the VLR

assigns a new TMSI with the Location Updating Accept, which is acknowledged by

the TMSI Reallocation Complete. In following Location Updates with the same

MSC, the ME sends the TMSI instead of the IMSI in the Location Updating

Request.

[[figure-imsi-regular]]

.Location Updating in 2G CS with IMSI

["mscgen"]

----

msc {

  hscale="1.75";

  ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"],

  HLR [label="HLR"];

  // BTS <=> BSC: RSL

  // BSC <=> MSC: BSSAP, RNSAP

  // MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002)

  ME   => BTS [label="Location Updating Request"];

  BTS  => BSC [label="Location Updating Request"];

  BSC  => MSC [label="Location Updating Request"];

  --- [label="VLR requests new authentication challenges for this IMSI if necessary"];

  MSC  => HLR [label="Send Auth Info Request"];

  MSC <=  HLR [label="Send Auth Info Result"];

  ---;

  BSC <=  MSC [label="Authentication Request"];

  BTS <=  BSC [label="Authentication Request"];

  ME  <=  BTS [label="Authentication Request"];

  ME   => BTS [label="Authentication Response"];

  BTS  => BSC [label="Authentication Response"];

  BSC  => MSC [label="Authentication Response"];

  BSC <=  MSC [label="Classmark Enquiry"];

  BTS <=  BSC [label="Classmark Enquiry"];

  ME  <=  BTS [label="Classmark Enquiry"];

  ME   => BTS [label="Classmark Change"];

  BTS  => BSC [label="Classmark Change"];

  BSC  => MSC [label="Classmark Update"];

  BSC <=  MSC [label="Physical Channel Reconfiguration"];

  BTS <=  BSC [label="Ciphering Mode Command"];

  ME  <=  BTS [label="Ciphering Mode Command"];

  ME  =>  BTS [label="Ciphering Mode Complete"];

  BTS  => BSC [label="Ciphering Mode Complete"];

  BSC  => MSC [label="Ciphering Mode Complete"];

  MSC  => HLR [label="Update Location Request"];

  MSC <=  HLR [label="Insert Subscriber Data Request"];

  MSC  => HLR [label="Insert Subscriber Data Result"];

  MSC <=  HLR [label="Update Location Result"];

  BSC <=  MSC [label="Location Updating Accept"];

  BTS <=  BSC [label="Location Updating Accept"];

  ME  <=  BTS [label="Location Updating Accept"];

  ME   => BTS [label="TMSI Reallocation Complete"];

  BTS  => BSC [label="TMSI Reallocation Complete"];

  BSC  => MSC [label="TMSI Reallocation Complete"];

}

----

<<<

== Required Changes

=== Pseudonymous IMSI Storage in the HLR

The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related

counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one

pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs

only during the transition phase from the old pseudonymous IMSI to the new one.

The amount of available IMSIs must be higher than the amount of subscribers

registered with the HLR. If the amount of available IMSIs is too short, the HLR

can delay assigning new pseudonymous IMSIs until new IMSIs are available again.

.Examples for additional subscriber data in HLR

|===

| Subscriber ID | imsi_pseudo | imsi_pseudo_i

// example IMSIs taken from Wikipedia

| 123

| 310150123456789

| 1

| 234

| 502130123456789

| 1

| 234

| 460001357924680

| 2

|===

==== imsi_pseudo

The value for imsi_pseudo is a random choice from the pool of available IMSIs

that the HLR controls. The pseudonymous IMSI must not be used by any subscriber

as pseudonymous IMSI yet, but may be the real IMSI of a subscriber.

==== imsi_pseudo_i

The counter imsi_pseudo_i indicates how often a subscriber's pseudonymous IMSI

was changed. The value is one for the first allocated pseudonymous IMSI of

a subscriber. When allocating a new pseudonymous IMSI for the same subscriber,

the new imsi_pseudo_i value is increased by one. The counter is used by the SIM

applet to detect and ignore outdated requests related to changing the

pseudonymous IMSI.

=== SIM Provisioning

=== Successful Location Update With Pseudonymous IMSI

// HLR may choose not to give out next IMSI if it is short on available IMSIS

=== Next Pseudonymous IMSI Arrives Via SMS

== Error Scenarios

=== Next Pseudonymous IMSI SMS is Lost

=== SMS Arrives Late

== Reference Implementation with Source Code

== Recommendations for Real-World Implementations

=== ATT = 0

=== End to End Encryption of SMS

=== Warning the User if the IMSI Does Not Change

=== User-configurable Minimum Duration Between IMSI Changes

<<<

include::./common/chapters/gfdl.adoc[]