= 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 <>. 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 Process Update_Location_HLR (3GPP TS 29.002). 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="If necessary: VLR requests new authentication challenges for this IMSI"]; 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"]; --- [label="Process Update_Location_HLR (3GPP TS 29.002)"]; 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 [[hlr-imsi-pseudo-storage]] === 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 [options="header"] |=== | 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. [[hlr-imsi-pseudo-i]] ==== imsi_pseudo_i The counter imsi_pseudo_i indicates how often a subscriber's pseudonymous IMSI was changed. The value is 1 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 1. The counter is used by the SIM applet to detect and ignore outdated requests related to changing the pseudonymous IMSI. === SIM Provisioning The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI. [[sim-app]] ==== SIM applet The SIM is provisioned with a SIM applet, which is able to change the IMSI once the next pseudonymous IMSI arrives from the HLR. A reference implementation is provided in <>. ===== Counter Storage The following counter variables are stored in the SIM applet. [options="header",cols="20%,12%,68%"] |=== | Name | Initial value | Description | imsi_pseudo_i | 1 | See <>. | imsi_pseudo_lu | 0 | Amount of Location Updating procedures done with the same pseudonymous IMSI. | imsi_pseudo_lu_max | (decided by operator) | Maximum amount of Location Updating procedures done with the same pseudonymous IMSI, before the SIM applet shows a warning to the subscriber. |=== ===== Switch to Next Pseudonymous IMSI The SIM applet registers to a suitable SMS trigger (3GPP TS 03.19, Section 6.2). When an SMS from the HLR in the structure of <> 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 (initially 1 as in <>). The new value must be higher, otherwise the SMS should not be processed further. The SIM applet registers a timer with min_sleep_time from the SMS. When the timer triggers, the IMSI of the SIM is overwritten with the new pseudonymous IMSI, the TMSI and GSM Ciphering key Kc (3GPP TS 31.102, Section 4.4.3.1) are invalidated. 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, the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed to apply the new IMSI. // FIXME: do we need to enforce the LU now, with an arbitrary CM Service // Request, or would this only be necessary for Osmocom? (OS#4404) ===== Warning the Subscriber If the Pseudonymous IMSI Does Not Change An attacker could potentially block the next pseudonymous IMSI SMS on purpose. Because the SIM applet cannot decide the next pseudonymous IMSI, it would have the same pseudonymous IMSI for a long time. Then it could become feasible for an attacker to track the subscriber by their pseudonymous IMSI. Therefore the SIM applet should warn the subscriber if the pseudonymous IMSI does not change. The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS 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 displays a warning to the subscriber. [[process-update-location-hlr]] === Process Update_Location_HLR All IMSI Pseudonymization related changes to Process Update_Location_HLR (3GPP TS 29.002) are optional. Deviations from the existing specification that are outlined in this section are expected to be enabled or disabled entirely where IMSI pseudonymization is implemented. [[figure-imsi-pseudo]] .Process Update_Location_HLR with IMSI pseudonymization changes ["mscgen"] ---- msc { hscale="1.75"; MSC [label="MSC/VLR"], SMSC [label="SMS-SC"], HLR [label="HLR"]; MSC => HLR [label="Update Location Request"]; --- [label="If new pseudonymous IMSI was used: deallocate and cancel old pseudonymous IMSI"]; HLR box HLR [label="Deallocate old pseudonymous IMSI"]; MSC <= HLR [label="Cancel Location Request"]; MSC => HLR [label="Cancel Location Result"]; ---; MSC <= HLR [label="Insert Subscriber Data Request"]; MSC => HLR [label="Insert Subscriber Data Result"]; HLR box HLR [label="Start Next_Pseudo_IMSI_Timer"]; MSC <= HLR [label="Update Location Result"]; MSC box MSC [label="Finish Location Updating with ME"], HLR box HLR [label="Wait for Next_Pseudo_IMSI_Timer expiry"]; |||; ...; |||; HLR box HLR [label="Next_Pseudo_IMSI_Timer expired"]; HLR box HLR [label="\nAllocate new pseudonymous IMSI\nif subscriber has only one allocated\n"]; SMSC <= HLR [label="Next Pseudonymous IMSI SMS"]; SMSC box SMSC [label="Deliver SMS to ME"]; } ---- ==== Update Location Request When Update Location Request arrives, the HLR does not look up the subscriber by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the Update Location Request, this is followed by the existing logic to continue with Insert Subscriber Data Request. ===== Update Location Request With New Pseudonymous IMSI If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was used (higher imsi_pseudo_i, see <>), this section applies. The older pseudonymous IMSI is deallocated in the HLR. This is done as early as possible, so the timeframe where two pseudonymous IMSI are allocated for one subscriber is short. A Cancel Location Request with the old pseudonymous IMSI is sent to the VLR, so the conflicting subscriber entry with the old pseudonymous IMSI is deleted from the VLR. Receiving a Cancel Location Result is followed by the existing logic to continue with Insert Subscriber Data Request. ===== Update Location Request With Old Pseudonymous IMSI If the subscriber has two pseudonymous IMSIs allocated, and the older entry was used (lower imsi_pseudo_i, see <>), the newer entry is _not_ deallocated. This could lock out the subscriber from the network if the SMS with the new pseudonymous IMSI arrives with a delay. ==== Insert Subscriber Data Result When Insert Subscriber Data Result arrives, a subscriber specific Next_Pseudo_IMSI_Timer starts. ==== Next_Pseudo_IMSI_Timer Expires If the subscriber has only one pseudonymous IMSI allocated, and the amount of available IMSIs in the HLR is high enough, a second pseudonymous IMSI and related imsi_pseudo_i gets allocated for the subscriber (as described in <>). If the subscriber still has only one pseudonymous IMSI, because not enough IMSIs were available in the HLR, the process is aborted here and no SMS with a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a new pseudonymous IMSI during the next Location Updating Procedure, if the HLR has enough IMSIs available at that point. An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous IMSI (higher imsi_pseudo_i, see <>) and related imsi_pseudo_i value. [[sms-structure]] ==== Next Pseudonymous IMSI SMS Structure .Next pseudonymous IMSI SMS structure [packetdiag] ---- { colwidth = 32 0-31: IMSI_PSEUDO_I 32-63: MIN_SLEEP_TIME 64-119: IMSI_PSEUDO 120-127: PAD } ---- // FIXME IMPORTANT: This is a draft. The structure is likely to change after the reference implementation phase. IMSI_PSEUDO_I: 32 bits:: See <>. MIN_SLEEP_TIME: 32 bits:: Amount of seconds, which the SIM applet should wait before changing to the new pseudonymous IMSI. Since it is unclear when the SMS will arrive (ME might be turned off), this is a minimum amount. IMSI_PSEUDO: 60 bits:: Telephony Binary Coded Decimal (TBCD, 3GPP TS 29.002) version of the next pseudonymous IMSI. PAD: 8 bits:: Padding at the end, should be filled with 1111 as in the TBCD specification. == Error Scenarios === Next Pseudonymous IMSI SMS is Lost If the SMS with the next pseudonymous IMSI does not arrive, the SIM will start the next Location Updating Procedure with the old pseudonymous IMSI. Because the HLR has both the old and the new pseudonymous IMSI allocated at this point, the subscriber is not locked out of the network. === Next Pseudonymous IMSI SMS arrives out of order The next pseudonymous IMSI SMS may arrive out of order. Either, because the network is not able to deliver them in order, or even because an attacker would perform a replay attack. If the SMS arrives out of order, the imsi_pseudo_i counter will not be higher than the value the SIM applet (<>) has stored. Therefore, the applet will discard the message and the subscriber is not locked out of the network. // === SMS Arrives Before Timer Expires // FIXME: OS#4486 == Recommendations for Real-World Implementations === BCCH SI3: ATT = 0 When changing from one pseudonymous IMSI to the next, it is important that the ME does not detach from the network. Otherwise it would be trivial for an attacker to correlate the detach with the attach of the same ME with the next pseudonymous IMSI. This is controlled with the ATT flag in the SYSTEM INFORMATION TYPE 3 (SI3) message on the Broadcast Control Channel (BCCH), see 3GPP TS 44.018 Section 10.5.2.11. It must be set to 0. // FIXME: verify how it set with operators in germany (OS#4404) === End to End Encryption of SMS When deploying the IMSI pseudonymization, the operator should make sure that the next pseudonymous IMSI SMS (<>) cannot be read or modified by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the network. The safest way to protect the next pseudonymous IMSI SMS is a layer of end to end encryption from the HLR to the SIM. It was considered for this specification, but found to be out of scope. === User-configurable Minimum Duration Between IMSI Changes It may be desirable to let subscribers configure their minimum duration between IMSI changes. This allows subscribers with a high privacy requirement to switch their pseudonymous IMSI more often, and it allows the pseudonymous IMSI change to happen less frequently if it is distracting to the subscriber. How distracting the pseudonymous IMSI change is, depends on the ME. The following examples were observed: // FIXME: might need an update after SYS#4481 * 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. [[reference-src]] == Reference Implementation with Source Code A reference implementation for the SIM applet (<>) is available in source code under the Apache-2.0 license at: https://osmocom.org/projects/imsi-pseudo The HLR modifications described in <> and <> were implemented for reference in OsmoHLR from the Osmocom project, licensed under AGPL-3.0. Information about the source code and related branches for IMSI pseudonymization can be found at the above URL as well. <<< include::./common/chapters/gfdl.adoc[]