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 |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 56 | with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns |
| 57 | a new TMSI with the Location Updating Accept, which is acknowledged by the TMSI |
| 58 | Reallocation Complete. In following Location Updates with the same MSC, the ME |
| 59 | sends the TMSI instead of the IMSI in the Location Updating Request. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 60 | |
| 61 | [[figure-imsi-regular]] |
| 62 | .Location Updating in 2G CS with IMSI |
| 63 | ["mscgen"] |
| 64 | ---- |
| 65 | msc { |
| 66 | hscale="1.75"; |
| 67 | ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"], |
| 68 | HLR [label="HLR"]; |
| 69 | |
| 70 | // BTS <=> BSC: RSL |
| 71 | // BSC <=> MSC: BSSAP, RNSAP |
| 72 | // MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002) |
| 73 | |
| 74 | ME => BTS [label="Location Updating Request"]; |
| 75 | BTS => BSC [label="Location Updating Request"]; |
| 76 | BSC => MSC [label="Location Updating Request"]; |
| 77 | |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 78 | --- [label="If necessary: VLR requests new authentication challenges for this IMSI"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 79 | MSC => HLR [label="Send Auth Info Request"]; |
| 80 | MSC <= HLR [label="Send Auth Info Result"]; |
| 81 | ---; |
| 82 | |
| 83 | BSC <= MSC [label="Authentication Request"]; |
| 84 | BTS <= BSC [label="Authentication Request"]; |
| 85 | ME <= BTS [label="Authentication Request"]; |
| 86 | ME => BTS [label="Authentication Response"]; |
| 87 | BTS => BSC [label="Authentication Response"]; |
| 88 | BSC => MSC [label="Authentication Response"]; |
| 89 | BSC <= MSC [label="Classmark Enquiry"]; |
| 90 | BTS <= BSC [label="Classmark Enquiry"]; |
| 91 | ME <= BTS [label="Classmark Enquiry"]; |
| 92 | ME => BTS [label="Classmark Change"]; |
| 93 | BTS => BSC [label="Classmark Change"]; |
| 94 | BSC => MSC [label="Classmark Update"]; |
| 95 | BSC <= MSC [label="Physical Channel Reconfiguration"]; |
| 96 | BTS <= BSC [label="Ciphering Mode Command"]; |
| 97 | ME <= BTS [label="Ciphering Mode Command"]; |
Oliver Smith | 8c81b55 | 2020-04-07 08:44:56 +0200 | [diff] [blame] | 98 | ME => BTS [label="Ciphering Mode Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 99 | BTS => BSC [label="Ciphering Mode Complete"]; |
| 100 | BSC => MSC [label="Ciphering Mode Complete"]; |
| 101 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 102 | --- [label="Process Update_Location_HLR (3GPP TS 29.002)"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 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"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 107 | ---; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 108 | |
| 109 | BSC <= MSC [label="Location Updating Accept"]; |
| 110 | BTS <= BSC [label="Location Updating Accept"]; |
| 111 | ME <= BTS [label="Location Updating Accept"]; |
| 112 | ME => BTS [label="TMSI Reallocation Complete"]; |
| 113 | BTS => BSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 114 | BSC => MSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 115 | } |
| 116 | ---- |
| 117 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 118 | <<< |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 119 | == Required Changes |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 120 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 121 | [[hlr-imsi-pseudo-storage]] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 122 | === Pseudonymous IMSI Storage in the HLR |
| 123 | |
| 124 | The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related |
| 125 | counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one |
| 126 | pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs |
| 127 | only during the transition phase from the old pseudonymous IMSI to the new one. |
| 128 | The amount of available IMSIs must be higher than the amount of subscribers |
| 129 | registered with the HLR. If the amount of available IMSIs is too short, the HLR |
| 130 | can delay assigning new pseudonymous IMSIs until new IMSIs are available again. |
| 131 | |
| 132 | .Examples for additional subscriber data in HLR |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 133 | [options="header"] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 134 | |=== |
| 135 | | Subscriber ID | imsi_pseudo | imsi_pseudo_i |
| 136 | // example IMSIs taken from Wikipedia |
| 137 | | 123 |
| 138 | | 310150123456789 |
| 139 | | 1 |
| 140 | |
| 141 | | 234 |
| 142 | | 502130123456789 |
| 143 | | 1 |
| 144 | |
| 145 | | 234 |
| 146 | | 460001357924680 |
| 147 | | 2 |
| 148 | |=== |
| 149 | |
| 150 | ==== imsi_pseudo |
| 151 | |
| 152 | The value for imsi_pseudo is a random choice from the pool of available IMSIs |
| 153 | that the HLR controls. The pseudonymous IMSI must not be used by any subscriber |
| 154 | as pseudonymous IMSI yet, but may be the real IMSI of a subscriber. |
| 155 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 156 | [[hlr-imsi-pseudo-i]] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 157 | ==== imsi_pseudo_i |
| 158 | |
| 159 | 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] | 160 | was changed. The value is 1 for the first allocated pseudonymous IMSI of a |
| 161 | subscriber. When allocating a new pseudonymous IMSI for the same subscriber, |
| 162 | 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] | 163 | applet to detect and ignore outdated requests related to changing the |
| 164 | pseudonymous IMSI. |
| 165 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 166 | === SIM Provisioning |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 167 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 168 | The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous |
| 169 | IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI. |
| 170 | |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 171 | [[sim-app]] |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 172 | ==== SIM applet |
| 173 | |
| 174 | The SIM is provisioned with a SIM applet, which is able to change the IMSI once |
| 175 | the next pseudonymous IMSI arrives from the HLR. A reference implementation is |
| 176 | provided in <<reference-src>>. |
| 177 | |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 178 | ===== Counter Storage |
| 179 | |
| 180 | The following counter variables are stored in the SIM applet. |
| 181 | |
| 182 | [options="header",cols="20%,12%,68%"] |
| 183 | |=== |
| 184 | | Name | Initial value | Description |
| 185 | |
| 186 | | imsi_pseudo_i |
| 187 | | 1 |
| 188 | | See <<hlr-imsi-pseudo-i>>. |
| 189 | |
| 190 | | imsi_pseudo_lu |
| 191 | | 0 |
| 192 | | Amount of Location Updating procedures done with the same pseudonymous IMSI. |
| 193 | |
| 194 | | imsi_pseudo_lu_max |
| 195 | | (decided by operator) |
| 196 | | Maximum amount of Location Updating procedures done with the same |
| 197 | pseudonymous IMSI, before the SIM applet shows a warning to the subscriber. |
| 198 | |=== |
| 199 | |
| 200 | ===== Switch to Next Pseudonymous IMSI |
| 201 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 202 | The SIM applet registers to a suitable SMS trigger (3GPP TS 03.19, Section |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 203 | 6.2). When an SMS from the HLR in the structure of <<sms-structure>> arrives, |
| 204 | the applet must verify that the SMS is not outdated by comparing imsi_pseudo_i |
| 205 | from the SMS with the last imsi_pseudo_i that was used when changing the IMSI |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 206 | (initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher, |
| 207 | otherwise the SMS should not be processed further. |
| 208 | |
| 209 | The SIM applet registers a timer with min_sleep_time from the SMS. When the |
| 210 | timer triggers, the IMSI of the SIM is overwritten with the new pseudonymous |
| 211 | IMSI, the TMSI and GSM Ciphering key Kc (3GPP TS 31.102, Section 4.4.3.1) are |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 212 | invalidated. The current imsi_pseudo_i from the SMS is stored in the SIM applet |
| 213 | to compare it with the next SMS. imsi_pseudo_lu is reset to 0. Afterwards, |
| 214 | the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed |
| 215 | to apply the new IMSI. |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 216 | |
| 217 | // FIXME: do we need to enforce the LU now, with an arbitrary CM Service |
| 218 | // Request, or would this only be necessary for Osmocom? (OS#4404) |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 219 | |
| 220 | ===== Warning the Subscriber If the Pseudonymous IMSI Does Not Change |
| 221 | |
| 222 | An attacker could potentially block the next pseudonymous IMSI SMS on purpose. |
| 223 | Because the SIM applet cannot decide the next pseudonymous IMSI, it would have |
| 224 | the same pseudonymous IMSI for a long time. Then it could become feasible for |
| 225 | an attacker to track the subscriber by their pseudonymous IMSI. Therefore the |
| 226 | SIM applet should warn the subscriber if the pseudonymous IMSI does not change. |
| 227 | |
| 228 | The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS |
| 229 | 03.19, Section 6.2) and increases imsi_pseudo_lu by 1 when the event is |
| 230 | triggered. If imsi_pseudo_lu reaches imsi_pseudo_lu_max, the SIM applet |
| 231 | displays a warning to the subscriber. |
| 232 | |
Oliver Smith | bb8d912 | 2020-04-08 14:58:50 +0200 | [diff] [blame] | 233 | [[process-update-location-hlr]] |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 234 | === Process Update_Location_HLR |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 235 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 236 | All IMSI Pseudonymization related changes to Process Update_Location_HLR |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 237 | (3GPP TS 29.002) are optional. Deviations from the existing specification that |
| 238 | are outlined in this section are expected to be enabled or disabled entirely |
| 239 | where IMSI pseudonymization is implemented. |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 240 | |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 241 | [[figure-imsi-pseudo]] |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 242 | .Process Update_Location_HLR with IMSI pseudonymization changes |
| 243 | ["mscgen"] |
| 244 | ---- |
| 245 | msc { |
| 246 | hscale="1.75"; |
| 247 | MSC [label="MSC/VLR"], SMSC [label="SMS-SC"], HLR [label="HLR"]; |
| 248 | |
| 249 | MSC => HLR [label="Update Location Request"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 250 | |
| 251 | --- [label="If new pseudonymous IMSI was used: deallocate and cancel old pseudonymous IMSI"]; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 252 | HLR box HLR [label="Deallocate old pseudonymous IMSI"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 253 | MSC <= HLR [label="Cancel Location Request"]; |
| 254 | MSC => HLR [label="Cancel Location Result"]; |
| 255 | ---; |
| 256 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 257 | MSC <= HLR [label="Insert Subscriber Data Request"]; |
| 258 | MSC => HLR [label="Insert Subscriber Data Result"]; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 259 | HLR box HLR [label="Start Next_Pseudo_IMSI_Timer"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 260 | MSC <= HLR [label="Update Location Result"]; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 261 | MSC box MSC [label="Finish Location Updating with ME"], |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 262 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 263 | HLR box HLR [label="Wait for Next_Pseudo_IMSI_Timer expiry"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 264 | |||; |
| 265 | ...; |
| 266 | |||; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 267 | HLR box HLR [label="Next_Pseudo_IMSI_Timer expired"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 268 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 269 | HLR box HLR [label="\nAllocate new pseudonymous IMSI\nif subscriber has only one allocated\n"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 270 | SMSC <= HLR [label="Next Pseudonymous IMSI SMS"]; |
| 271 | SMSC box SMSC [label="Deliver SMS to ME"]; |
| 272 | } |
| 273 | ---- |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 274 | |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 275 | ==== Update Location Request |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 276 | |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 277 | When Update Location Request arrives, the HLR does not look up the subscriber |
| 278 | by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 279 | two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the |
| 280 | Update Location Request, this is followed by the existing logic to continue |
| 281 | with Insert Subscriber Data Request. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 282 | |
| 283 | ===== Update Location Request With New Pseudonymous IMSI |
| 284 | |
| 285 | If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was |
| 286 | used (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), this section applies. |
| 287 | The older pseudonymous IMSI is deallocated in the HLR. This is done as early |
| 288 | as possible, so the timeframe where two pseudonymous IMSI are allocated for one |
| 289 | subscriber is short. |
| 290 | |
| 291 | A Cancel Location Request with the old pseudonymous IMSI is sent to the VLR, so |
| 292 | the conflicting subscriber entry with the old pseudonymous IMSI is deleted from |
| 293 | the VLR. Receiving a Cancel Location Result is followed by the existing logic |
| 294 | to continue with Insert Subscriber Data Request. |
| 295 | |
| 296 | ===== Update Location Request With Old Pseudonymous IMSI |
| 297 | |
| 298 | If the subscriber has two pseudonymous IMSIs allocated, and the older entry was |
| 299 | used (lower imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_ |
| 300 | deallocated. This could lock out the subscriber from the network if the SMS |
| 301 | with the new pseudonymous IMSI arrives with a delay. |
| 302 | |
| 303 | ==== Insert Subscriber Data Result |
| 304 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 305 | When Insert Subscriber Data Result arrives, a subscriber specific |
| 306 | Next_Pseudo_IMSI_Timer starts. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 307 | |
| 308 | ==== Next_Pseudo_IMSI_Timer Expires |
| 309 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 310 | If the subscriber has only one pseudonymous IMSI allocated, and the amount of |
| 311 | available IMSIs in the HLR is high enough, a second pseudonymous IMSI and |
| 312 | related imsi_pseudo_i gets allocated for the subscriber (as described in |
| 313 | <<hlr-imsi-pseudo-storage>>). |
| 314 | |
| 315 | If the subscriber still has only one pseudonymous IMSI, because not enough |
| 316 | IMSIs were available in the HLR, the process is aborted here and no SMS with |
| 317 | a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a |
| 318 | new pseudonymous IMSI during the next Location Updating Procedure, if the HLR |
| 319 | has enough IMSIs available at that point. |
| 320 | |
| 321 | An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous |
| 322 | IMSI (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>) and related |
| 323 | imsi_pseudo_i value. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 324 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 325 | [[sms-structure]] |
| 326 | ==== Next Pseudonymous IMSI SMS Structure |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 327 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 328 | .Next pseudonymous IMSI SMS structure |
| 329 | [packetdiag] |
| 330 | ---- |
| 331 | { |
| 332 | colwidth = 32 |
| 333 | |
| 334 | 0-31: IMSI_PSEUDO_I |
| 335 | 32-63: MIN_SLEEP_TIME |
| 336 | 64-119: IMSI_PSEUDO |
| 337 | 120-127: PAD |
| 338 | } |
| 339 | ---- |
| 340 | |
Oliver Smith | a0354de | 2020-04-09 15:13:38 +0200 | [diff] [blame^] | 341 | // FIXME |
| 342 | IMPORTANT: This is a draft. The structure is likely to change after the |
| 343 | reference implementation phase. |
| 344 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 345 | IMSI_PSEUDO_I: 32 bits:: |
| 346 | See <<hlr-imsi-pseudo-i>>. |
| 347 | |
| 348 | MIN_SLEEP_TIME: 32 bits:: |
| 349 | Amount of seconds, which the SIM applet should wait before changing to the new |
| 350 | pseudonymous IMSI. Since it is unclear when the SMS will arrive (ME might be |
| 351 | turned off), this is a minimum amount. |
| 352 | |
| 353 | IMSI_PSEUDO: 60 bits:: |
| 354 | Telephony Binary Coded Decimal (TBCD, 3GPP TS 29.002) version of the next |
| 355 | pseudonymous IMSI. |
| 356 | |
| 357 | PAD: 8 bits:: |
| 358 | Padding at the end, should be filled with 1111 as in the TBCD specification. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 359 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 360 | == Error Scenarios |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 361 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 362 | === Next Pseudonymous IMSI SMS is Lost |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 363 | |
| 364 | If the SMS with the next pseudonymous IMSI does not arrive, the SIM will start |
| 365 | the next Location Updating Procedure with the old pseudonymous IMSI. Because |
| 366 | the HLR has both the old and the new pseudonymous IMSI allocated at this point, |
| 367 | the subscriber is not locked out of the network. |
| 368 | |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 369 | === Next Pseudonymous IMSI SMS arrives out of order |
| 370 | |
| 371 | The next pseudonymous IMSI SMS may arrive out of order. Either, because the |
| 372 | network is not able to deliver them in order, or even because an attacker would |
| 373 | perform a replay attack. |
| 374 | |
| 375 | If the SMS arrives out of order, the imsi_pseudo_i counter will not be higher |
| 376 | than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet |
| 377 | will discard the message and the subscriber is not locked out of the network. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 378 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 379 | // === SMS Arrives Before Timer Expires |
| 380 | // FIXME: OS#4486 |
| 381 | |
| 382 | [[reference-src]] |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 383 | == Reference Implementation with Source Code |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 384 | |
Oliver Smith | bb8d912 | 2020-04-08 14:58:50 +0200 | [diff] [blame] | 385 | A reference implementation for the SIM applet (<<sim-app>>) is available in |
| 386 | source code under the Apache-2.0 license at: |
| 387 | |
| 388 | https://osmocom.org/projects/imsi-pseudo |
| 389 | |
| 390 | The HLR modifications described in <<hlr-imsi-pseudo-storage>> and |
| 391 | <<process-update-location-hlr>> were implemented for reference in OsmoHLR from |
| 392 | the Osmocom project, licensed under AGPL-3.0. Information about the source code |
| 393 | and related branches for IMSI pseudonymization can be found at the above URL as |
| 394 | well. |
| 395 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 396 | == Recommendations for Real-World Implementations |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 397 | |
Oliver Smith | 18bf9bb | 2020-04-08 15:26:59 +0200 | [diff] [blame] | 398 | === BCCH SI3: ATT = 0 |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 399 | |
Oliver Smith | 18bf9bb | 2020-04-08 15:26:59 +0200 | [diff] [blame] | 400 | When changing from one pseudonymous IMSI to the next, it is important that the |
| 401 | ME does not detach from the network. Otherwise it would be trivial for an |
| 402 | attacker to correlate the detach with the attach of the same ME with the next |
| 403 | pseudonymous IMSI. |
| 404 | |
| 405 | This is controlled with the ATT flag in the SYSTEM INFORMATION TYPE 3 (SI3) |
| 406 | message on the Broadcast Control Channel (BCCH), see 3GPP TS 44.018 Section |
| 407 | 10.5.2.11. It must be set to 0. |
| 408 | |
| 409 | // FIXME: verify how it set with operators in germany (OS#4404) |
| 410 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 411 | === End to End Encryption of SMS |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 412 | |
| 413 | When deploying the IMSI pseudonymization, the operator should make sure that |
| 414 | the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified |
| 415 | by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the |
| 416 | pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the |
| 417 | network. |
| 418 | |
| 419 | The safest way to protect the next pseudonymous IMSI SMS is a layer of end to |
| 420 | end encryption from the HLR to the SIM. It was considered for this |
| 421 | specification, but found to be out of scope. |
| 422 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 423 | === User-configurable Minimum Duration Between IMSI Changes |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 424 | |
Oliver Smith | a0354de | 2020-04-09 15:13:38 +0200 | [diff] [blame^] | 425 | It may be desirable to let subscribers configure their minimum duration between |
| 426 | IMSI changes. This allows subscribers with a high privacy requirement to switch |
| 427 | their pseudonymous IMSI more often, and it allows the pseudonymous IMSI change |
| 428 | to happen less frequently if it is distracting to the subscriber. |
| 429 | |
| 430 | How distracting the pseudonymous IMSI change is, depends on the ME. The |
| 431 | following examples were observed: |
| 432 | |
| 433 | // FIXME: might need an update after SYS#4481 |
| 434 | |
| 435 | * A Samsung GT-I9100 Galaxy SII smartphone with Android 4.0.3 displays a |
| 436 | message at the bottom of the screen for about 5 seconds, but the user |
| 437 | interface remains usable. |
| 438 | * A Samsung GT-E1200 feature phone displays a waiting screen for 16 to 17 |
| 439 | seconds and is unusable during that time. |
| 440 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 441 | <<< |
| 442 | include::./common/chapters/gfdl.adoc[] |