Cellular Network Infrastructure » IMSI Pseudonymization

A long-standing issue in the 3GPP specifications for cellular mobile

communications starting from 2G (GSM) is, that mobile phones and

Identity (IMSI) unencrypted over the air.  Each IMSI is a unique identifier for

the subscriber. Therefore, most people can be uniquely identified by recording

the IMSI that their ME is sending.

The 3GPP specifications provide means for implementations to send the

IMSI less often by using the Temporary Mobile Subscriber Identity (TMSI)

where possible.  However, the decision on when to use IMSI or TMSI is

entirely on the networks side, without any control by the ME or even the

subscriber.

This leads to a variety of attacks on subscriber location privacy, including

the use of passive air-interface sniffing as well as false base station

attacks, where an attacker impersonates a base station which

subsequently inquires every ME about its IMSI.

Some related devices have been termed _IMSI catchers_ or _Stingray_ in

both scientific literature as well as mainstream media. IMSI catchers have

become small and affordable during the last decade; criminals actors

and in some cases even tabloid journalists without much budget have

reportedly used them to track anybody with a mobile phone.

identity (IMSI) is not transmitted over the air interface anymore.

Rather, a concealed version of it is transmitted (3GPP TS 33.501,

Section 6.12.2).  The 5G SUCI mechanism can not be used 1:1 for previous

generations of cellular networks as it relies on extending the

subscriber identity from the small, 15-decimal-digit IMSI to a much

larger SUPI (Subscriber Permanent Identifier) only available in 5G.

No mechanism for increasing subscriber identity and location privacy on

the radio interface has been specified for the previous cellular

technologies 2G (GSM), 3G (UMTS) and 4G (LTE).  Meanwhile, pure 5G

networks are and will remain rare for many years to come, as operators

have to support billions of deployed legacy pre-5G ME.  Operating

combined 5G + previous technology networks enables the so-called

"downgrade attacks" where the attacker blocks access to 5G e.g. by means

of jamming/interference, and hence triggers the ME to use a previous

generation which is still susceptible to the attacks.

This specification proposes a different approach to conceal the

IMSI for legacy 2G, 3G and 4G networks.

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

SIM/USIM with the new value. The only components in the network that need to be

changed in order to support this mechanism are the SIM/USIM and the

HLR/HSS.  All other elements (like BTS, NodeB, eNodeB, BSC, RNC, MME,

MSC/VLR, SGSN, GGSN, S-GW, P-GW, ...) remain as-is, without any changes

to their specification or implementation.

Constraining the required changes to only two elements in the network

enables quick adoption potential for the proposed mechanism.

Furthermore, as SIM/USIM and HLR/HSS are the only two elements under control

of a Mobile Virtual Network Operator (MVNO), this mechanism can be

deployed by a MVNO without any changes to the operators of the physical

infrastructure (MNO).

Every subscriber's SIM/USIM is provisioned with the IMSI and secret

cryptographic keys (Ki or K+OP[c]).  The same IMSI and key data is also provisioned

into the HLR/HSS, the central subscriber database of a cellular network.

In a number of different situations, the IMSI is sent over the air

interface and back-haul towards 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/USIM 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>>.

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

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

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

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

However, the allocation of the TMSI is optional (the network may choose

to not perform it), and particularly at mobility changes across the

MSC/VLR boundary, or even across the PLMN boundary, the TMSI allocated

by the previouis network element may not be known, and an IMSI based

Location Updating procedure used.

Furthermore, at any given point in time, a legitimate network or a rogue

base station can inquire the IMSI from the ME using the "MM IDENTITY

REQUEST (IMSI)" command.

This section covers the changes / enhancements required

compared to the existing 3GPP specifications.

=== Pseudonymous IMSI Storage in the HLR/HSS

The HLR/HSS 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.

Subsequently, the amount of available IMSIs must be higher than the

amount of subscribers registered with the HLR/HSS. If the amount of

available IMSIs is too small, the HLR/HSS could delay assigning new

pseudonymous IMSIs until new IMSIs are available again.

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

IMSIs that the HLR/HSS controls. The pseudonymous IMSI must not be used

by any subscriber as pseudonymous IMSI yet, but may be the real IMSI of

a subscriber.

The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI

the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM

=== SIM/USIM Provisioning

IMSI pseudonymization as specified by this document works with

traditional SIM (used i 2G), as well as with USIM (used from 3G

onwards).

The initial IMSI provisioned in the SIM/USIM is provisioned as the initial

pseudonymous IMSI in the HLR/HSS.

SIM/USIM have long supported the installation and operation of

additional applets on the card itself.  The programming language and

runtime environment for such applets is an implementation detail.

However, the industry has converged around JavaCards with related

additional APIs specific to SIM, UICC and USIM.  Depending on the card

profile / provisioning, it is possible for such applets to access the

card file system and modify files on the card, such as the file storing

the IMSI.

A SIM/USIM compatible with this specification is provisioned with a SIM

applet, which is able to change the IMSI once the next pseudonymous IMSI

arrives from the HLR/HSS. A reference implementation is provided in

<<reference-src>>.

6.2). When an SMS from the HLR/HSS in the structure of <<sms-structure>> arrives,

the applet must verify that the SMS is not outdated by comparing `imsi_pseudo_i`

from the SMS with the last `imsi_pseudo_i` that was used when changing the IMSI

timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous

31.102). The current `imsi_pseudo_i` from the SMS is stored in the

SIM applet to compare it with the next SMS. `imsi_pseudo_lu` is reset to 0. Afterwards,

03.19, Section 6.2) and increases `imsi_pseudo_lu` by 1 when the event is

triggered. If `imsi_pseudo_lu` reaches `imsi_pseudo_lu_max`, the SIM applet

When Update Location Request arrives, the HLR/HSS does not look up the subscriber

used (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), this section applies.

The older pseudonymous IMSI is deallocated in the HLR/HSS. This is done as early

used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_

available IMSIs in the HLR/HSS is high enough, a second pseudonymous IMSI and

related `imsi_pseudo_i` gets allocated for the subscriber (as described in

IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with

new pseudonymous IMSI during the next Location Updating Procedure, if

the HLR/HSS has enough IMSIs available at that point.

IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related

`imsi_pseudo_i` value.

If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start

the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point,

If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher

pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the

end encryption from the HLR/HSS to the SIM/USIM.  The existing means for OTA SMS

The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and