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 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 5 | === Protecting the IMSI on the Radio Interface is Desirable |
| 6 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 7 | A long-standing issue in the 3GPP specifications is, that mobile phones and |
| 8 | other mobile equipment (ME) have to send the International Mobile Subscriber |
| 9 | Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the |
| 10 | person who bought the associated Subscriber Identity Module (SIM) used in the |
| 11 | ME. Therefore most people can be uniquely identified by recording the IMSI that |
| 12 | 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] | 13 | send the IMSI less often, by using the Temporary Mobile Subscriber Identity |
| 14 | (TMSI) where possible. |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 15 | |
| 16 | But this is not enough. So-called IMSI catchers were invented and are used to |
| 17 | not only record IMSIs when they have to be sent. But also to force ME to send |
| 18 | their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have |
| 19 | become small and affordable, even criminals actors without much budget can use |
| 20 | them to track anybody with a mobile phone. |
| 21 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 22 | === Summary of Proposed Solution |
| 23 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 24 | The solution presented in this document is to periodically change the IMSI of |
| 25 | the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR) |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 26 | or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM |
| 27 | via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the |
| 28 | SIM with the new value. The only component that needs to be changed in the |
| 29 | network besides the SIM is the HLR/HSS, therefore it should be possible even |
| 30 | for a Mobile Virtual Network Operator (MVNO) to deploy this privacy |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 31 | enhancement. |
| 32 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 33 | === Summary of Existing Location Updating Procedures in RAN and CN |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 34 | |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 35 | The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a |
| 36 | subscriber, after the subscriber was added with the same data to the HLR/HSS. |
| 37 | In the Remote Access Network (RAN), the IMSI is sent over the air interface and |
| 38 | then transmitted to the Core Network (CN), where it is validated by the |
| 39 | HLR/HSS. The involved components vary by the generation of the network and |
| 40 | whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS) |
| 41 | connection, but the principle is the same. This document uses 2G CS Location |
| 42 | Updating for reference, as in <<figure-imsi-regular>>. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 43 | |
| 44 | The IMSI is transmitted in the Location Updating Request from ME. The VLR |
| 45 | needs an authentication challenge specific to the secret keys on the SIM to |
| 46 | authenticate the SIM, and looks the authentication challenges up by the IMSI. |
| 47 | If the VLR does not have any more authentication challenges for the IMSI (as it |
| 48 | happens when the VLR sees the IMSI for the first time), the VLR requests new |
| 49 | authentication challenges from the HLR. Then the HLR verifies that the IMSI is |
| 50 | known and, if it is unknown, sends back an error that will terminate the |
| 51 | Location Updating procedure. |
| 52 | |
| 53 | After the VLR found the authentication challenge, it authenticates the SIM, and |
| 54 | performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR |
| 55 | has the required information to finish the Location Updating, and continues |
| 56 | with an Update Location Request procedure with the HLR. Afterwards, the VLR |
| 57 | assigns a new TMSI with the Location Updating Accept, which is acknowledged by |
| 58 | the TMSI Reallocation Complete. In following Location Updates with the same |
| 59 | MSC, the ME sends the TMSI instead of the IMSI in the Location Updating |
| 60 | Request. |
| 61 | |
| 62 | [[figure-imsi-regular]] |
| 63 | .Location Updating in 2G CS with IMSI |
| 64 | ["mscgen"] |
| 65 | ---- |
| 66 | msc { |
| 67 | hscale="1.75"; |
| 68 | ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"], |
| 69 | HLR [label="HLR"]; |
| 70 | |
| 71 | // BTS <=> BSC: RSL |
| 72 | // BSC <=> MSC: BSSAP, RNSAP |
| 73 | // MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002) |
| 74 | |
| 75 | ME => BTS [label="Location Updating Request"]; |
| 76 | BTS => BSC [label="Location Updating Request"]; |
| 77 | BSC => MSC [label="Location Updating Request"]; |
| 78 | |
| 79 | --- [label="VLR requests new authentication challenges for this IMSI if necessary"]; |
| 80 | MSC => HLR [label="Send Auth Info Request"]; |
| 81 | MSC <= HLR [label="Send Auth Info Result"]; |
| 82 | ---; |
| 83 | |
| 84 | BSC <= MSC [label="Authentication Request"]; |
| 85 | BTS <= BSC [label="Authentication Request"]; |
| 86 | ME <= BTS [label="Authentication Request"]; |
| 87 | ME => BTS [label="Authentication Response"]; |
| 88 | BTS => BSC [label="Authentication Response"]; |
| 89 | BSC => MSC [label="Authentication Response"]; |
| 90 | BSC <= MSC [label="Classmark Enquiry"]; |
| 91 | BTS <= BSC [label="Classmark Enquiry"]; |
| 92 | ME <= BTS [label="Classmark Enquiry"]; |
| 93 | ME => BTS [label="Classmark Change"]; |
| 94 | BTS => BSC [label="Classmark Change"]; |
| 95 | BSC => MSC [label="Classmark Update"]; |
| 96 | BSC <= MSC [label="Physical Channel Reconfiguration"]; |
| 97 | BTS <= BSC [label="Ciphering Mode Command"]; |
| 98 | ME <= BTS [label="Ciphering Mode Command"]; |
Oliver Smith | 8c81b55 | 2020-04-07 08:44:56 +0200 | [diff] [blame] | 99 | ME => BTS [label="Ciphering Mode Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 100 | BTS => BSC [label="Ciphering Mode Complete"]; |
| 101 | BSC => MSC [label="Ciphering Mode Complete"]; |
| 102 | |
| 103 | MSC => HLR [label="Update Location Request"]; |
| 104 | MSC <= HLR [label="Insert Subscriber Data Request"]; |
| 105 | MSC => HLR [label="Insert Subscriber Data Result"]; |
| 106 | MSC <= HLR [label="Update Location Result"]; |
| 107 | |
| 108 | BSC <= MSC [label="Location Updating Accept"]; |
| 109 | BTS <= BSC [label="Location Updating Accept"]; |
| 110 | ME <= BTS [label="Location Updating Accept"]; |
| 111 | ME => BTS [label="TMSI Reallocation Complete"]; |
| 112 | BTS => BSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 113 | BSC => MSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 114 | } |
| 115 | ---- |
| 116 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 117 | <<< |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 118 | == Required Changes |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 119 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 120 | === Pseudonymous IMSI Storage in the HLR |
| 121 | |
| 122 | The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related |
| 123 | counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one |
| 124 | pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs |
| 125 | only during the transition phase from the old pseudonymous IMSI to the new one. |
| 126 | The amount of available IMSIs must be higher than the amount of subscribers |
| 127 | registered with the HLR. If the amount of available IMSIs is too short, the HLR |
| 128 | can delay assigning new pseudonymous IMSIs until new IMSIs are available again. |
| 129 | |
| 130 | .Examples for additional subscriber data in HLR |
| 131 | |=== |
| 132 | | Subscriber ID | imsi_pseudo | imsi_pseudo_i |
| 133 | // example IMSIs taken from Wikipedia |
| 134 | | 123 |
| 135 | | 310150123456789 |
| 136 | | 1 |
| 137 | |
| 138 | | 234 |
| 139 | | 502130123456789 |
| 140 | | 1 |
| 141 | |
| 142 | | 234 |
| 143 | | 460001357924680 |
| 144 | | 2 |
| 145 | |=== |
| 146 | |
| 147 | ==== imsi_pseudo |
| 148 | |
| 149 | The value for imsi_pseudo is a random choice from the pool of available IMSIs |
| 150 | that the HLR controls. The pseudonymous IMSI must not be used by any subscriber |
| 151 | as pseudonymous IMSI yet, but may be the real IMSI of a subscriber. |
| 152 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame^] | 153 | [[hlr-imsi-pseudo-i]] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 154 | ==== imsi_pseudo_i |
| 155 | |
| 156 | The counter imsi_pseudo_i indicates how often a subscriber's pseudonymous IMSI |
Oliver Smith | 8c81b55 | 2020-04-07 08:44:56 +0200 | [diff] [blame] | 157 | was changed. The value is 1 for the first allocated pseudonymous IMSI of a |
| 158 | subscriber. When allocating a new pseudonymous IMSI for the same subscriber, |
| 159 | the new imsi_pseudo_i value is increased by 1. The counter is used by the SIM |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 160 | applet to detect and ignore outdated requests related to changing the |
| 161 | pseudonymous IMSI. |
| 162 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 163 | === SIM Provisioning |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 164 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame^] | 165 | The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous |
| 166 | IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI. |
| 167 | |
| 168 | ==== SIM applet |
| 169 | |
| 170 | The SIM is provisioned with a SIM applet, which is able to change the IMSI once |
| 171 | the next pseudonymous IMSI arrives from the HLR. A reference implementation is |
| 172 | provided in <<reference-src>>. |
| 173 | |
| 174 | The SIM applet registers to a suitable SMS trigger (3GPP TS 03.19, Section |
| 175 | 6.2). When an SMS from the HLR in the format of <<sms-format>> arrives, the |
| 176 | applet must verify that the SMS is not outdated by comparing imsi_pseudo_i from |
| 177 | the SMS with the last imsi_pseudo_i that was used when changing the IMSI |
| 178 | (initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher, |
| 179 | otherwise the SMS should not be processed further. |
| 180 | |
| 181 | The SIM applet registers a timer with min_sleep_time from the SMS. When the |
| 182 | timer triggers, the IMSI of the SIM is overwritten with the new pseudonymous |
| 183 | IMSI, the TMSI and GSM Ciphering key Kc (3GPP TS 31.102, Section 4.4.3.1) are |
| 184 | invalidated. The current imsi_pseudo_i value is stored to compare it with the |
| 185 | next SMS. Afterwards, the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section |
| 186 | 6.4.7.1 is executed to apply the new IMSI. |
| 187 | |
| 188 | // FIXME: do we need to enforce the LU now, with an arbitrary CM Service |
| 189 | // Request, or would this only be necessary for Osmocom? (OS#4404) |
| 190 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 191 | === Successful Location Update With Pseudonymous IMSI |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 192 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame^] | 193 | // HLR may choose not to give out next IMSI if it is short on available IMSIs |
| 194 | |
| 195 | [[sms-format]] |
| 196 | ==== Format of the SMS |
| 197 | |
| 198 | * min_sleep_time |
| 199 | * imsi_pseudo |
| 200 | * imsi_pseudo_i |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 201 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 202 | === Next Pseudonymous IMSI Arrives Via SMS |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 203 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 204 | == Error Scenarios |
| 205 | === Next Pseudonymous IMSI SMS is Lost |
| 206 | === SMS Arrives Late |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 207 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame^] | 208 | // === SMS Arrives Before Timer Expires |
| 209 | // FIXME: OS#4486 |
| 210 | |
| 211 | [[reference-src]] |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 212 | == Reference Implementation with Source Code |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 213 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 214 | == Recommendations for Real-World Implementations |
| 215 | === ATT = 0 |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 216 | === End to End Encryption of SMS |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 217 | === Warning the User if the IMSI Does Not Change |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 218 | === User-configurable Minimum Duration Between IMSI Changes |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 219 | |
| 220 | <<< |
| 221 | include::./common/chapters/gfdl.adoc[] |