Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 1 | = Specification for IMSI Pseudonymization on the Radio Interface for 2G and Above |
| 2 | |
| 3 | == Introduction |
| 4 | |
| 5 | A long-standing issue in the 3GPP specifications is, that mobile phones and |
| 6 | other mobile equipment (ME) have to send the International Mobile Subscriber |
| 7 | Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the |
| 8 | person who bought the associated Subscriber Identity Module (SIM) used in the |
| 9 | ME. Therefore most people can be uniquely identified by recording the IMSI that |
| 10 | their ME is sending. Efforts are made in the 2G and above specifications to |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame^] | 11 | send the IMSI less often, by using the Temporary Mobile Subscriber Identity |
| 12 | (TMSI) where possible. |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 13 | |
| 14 | But this is not enough. So-called IMSI catchers were invented and are used to |
| 15 | not only record IMSIs when they have to be sent. But also to force ME to send |
| 16 | their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have |
| 17 | become small and affordable, even criminals actors without much budget can use |
| 18 | them to track anybody with a mobile phone. |
| 19 | |
| 20 | The solution presented in this document is to periodically change the IMSI of |
| 21 | the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR) |
| 22 | or Home Subscriber Service (HSS). The only component that needs to be changed |
| 23 | in the network besides the SIM is the HLR/HSS, therefore it should be possible |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame^] | 24 | even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 25 | enhancement. |
| 26 | |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame^] | 27 | == Location Updating |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 28 | |
| 29 | === Regular |
| 30 | |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame^] | 31 | The SIM is provisioned with the IMSI (3GPP TS 23.008 section 2.1.9) and |
| 32 | cryptographic keys, that it uses to authenticate with the network. In the |
| 33 | Remote Access Network (RAN), the IMSI is sent over the air interface and then |
| 34 | transmitted to the Core Network (CN), where it is validated by the HLR/HSS. |
| 35 | The involved components vary by the generation of the network and whether the |
| 36 | SIM is attempting a Circuit Switched (CS) or Packet Switched (PS) connection. |
| 37 | But the principle is the same and looks like <<figure-imsi-regular>> for 2G CS |
| 38 | Location Updating with IMSI. |
| 39 | |
| 40 | The IMSI is transmitted in the Location Updating Request from ME. The VLR |
| 41 | needs an authentication challenge specific to the secret keys on the SIM to |
| 42 | authenticate the SIM, and looks the authentication challenges up by the IMSI. |
| 43 | If the VLR does not have any more authentication challenges for the IMSI (as it |
| 44 | happens when the VLR sees the IMSI for the first time), the VLR requests new |
| 45 | authentication challenges from the HLR. Then the HLR verifies that the IMSI is |
| 46 | known and, if it is unknown, sends back an error that will terminate the |
| 47 | Location Updating procedure. |
| 48 | |
| 49 | After the VLR found the authentication challenge, it authenticates the SIM, and |
| 50 | performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR |
| 51 | has the required information to finish the Location Updating, and continues |
| 52 | with an Update Location Request procedure with the HLR. Afterwards, the VLR |
| 53 | assigns a new TMSI with the Location Updating Accept, which is acknowledged by |
| 54 | the TMSI Reallocation Complete. In following Location Updates with the same |
| 55 | MSC, the ME sends the TMSI instead of the IMSI in the Location Updating |
| 56 | Request. |
| 57 | |
| 58 | [[figure-imsi-regular]] |
| 59 | .Location Updating in 2G CS with IMSI |
| 60 | ["mscgen"] |
| 61 | ---- |
| 62 | msc { |
| 63 | hscale="1.75"; |
| 64 | ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"], |
| 65 | HLR [label="HLR"]; |
| 66 | |
| 67 | // BTS <=> BSC: RSL |
| 68 | // BSC <=> MSC: BSSAP, RNSAP |
| 69 | // MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002) |
| 70 | |
| 71 | ME => BTS [label="Location Updating Request"]; |
| 72 | BTS => BSC [label="Location Updating Request"]; |
| 73 | BSC => MSC [label="Location Updating Request"]; |
| 74 | |
| 75 | --- [label="VLR requests new authentication challenges for this IMSI if necessary"]; |
| 76 | MSC => HLR [label="Send Auth Info Request"]; |
| 77 | MSC <= HLR [label="Send Auth Info Result"]; |
| 78 | ---; |
| 79 | |
| 80 | BSC <= MSC [label="Authentication Request"]; |
| 81 | BTS <= BSC [label="Authentication Request"]; |
| 82 | ME <= BTS [label="Authentication Request"]; |
| 83 | ME => BTS [label="Authentication Response"]; |
| 84 | BTS => BSC [label="Authentication Response"]; |
| 85 | BSC => MSC [label="Authentication Response"]; |
| 86 | BSC <= MSC [label="Classmark Enquiry"]; |
| 87 | BTS <= BSC [label="Classmark Enquiry"]; |
| 88 | ME <= BTS [label="Classmark Enquiry"]; |
| 89 | ME => BTS [label="Classmark Change"]; |
| 90 | BTS => BSC [label="Classmark Change"]; |
| 91 | BSC => MSC [label="Classmark Update"]; |
| 92 | BSC <= MSC [label="Physical Channel Reconfiguration"]; |
| 93 | BTS <= BSC [label="Ciphering Mode Command"]; |
| 94 | ME <= BTS [label="Ciphering Mode Command"]; |
| 95 | ME => BTS [label="Ciphering Mode Complete"]; |
| 96 | BTS => BSC [label="Ciphering Mode Complete"]; |
| 97 | BSC => MSC [label="Ciphering Mode Complete"]; |
| 98 | |
| 99 | MSC => HLR [label="Update Location Request"]; |
| 100 | MSC <= HLR [label="Insert Subscriber Data Request"]; |
| 101 | MSC => HLR [label="Insert Subscriber Data Result"]; |
| 102 | MSC <= HLR [label="Update Location Result"]; |
| 103 | |
| 104 | BSC <= MSC [label="Location Updating Accept"]; |
| 105 | BTS <= BSC [label="Location Updating Accept"]; |
| 106 | ME <= BTS [label="Location Updating Accept"]; |
| 107 | ME => BTS [label="TMSI Reallocation Complete"]; |
| 108 | BTS => BSC [label="TMSI Reallocation Complete"]; |
| 109 | } |
| 110 | ---- |
| 111 | |
| 112 | === With IMSI Pseudonymization |
| 113 | |
| 114 | ==== SIM Provisioning |
| 115 | |
| 116 | ==== Successful Location Update With Pseudonymous IMSI |
| 117 | |
| 118 | ==== Next Pseudonymous IMSI Arrives Via SMS |
| 119 | |
| 120 | ==== Error Handling |
| 121 | |
| 122 | ===== SMS is Lost |
| 123 | |
| 124 | ===== SMS Arrives Late |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 125 | |
| 126 | == Implementation Notes |
| 127 | |
| 128 | === Source Code for Reference Implementation |
| 129 | |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame^] | 130 | === ATT = 0 required |
| 131 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 132 | === Warning the User if the IMSI Does Not Change |
| 133 | |
| 134 | === End to End Encryption of SMS |
| 135 | |
| 136 | === User-configurable Minimum Duration Between IMSI Changes |