| = 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 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 |
| |
| === 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[] |