Harald Welte | 9d63d6f | 2020-04-11 10:18:34 +0200 | [diff] [blame] | 1 | = Specification for IMSI Pseudonymization on the Radio Interface for 2G/3G/4G |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 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 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 7 | A long-standing issue in the 3GPP specifications for cellular mobile |
| 8 | communications starting from 2G (GSM) is, that mobile phones and |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 9 | other mobile equipment (ME) have to send the International Mobile Subscriber |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 10 | Identity (IMSI) unencrypted over the air. Each IMSI is a unique identifier for |
| 11 | the subscriber. Therefore, most people can be uniquely identified by recording |
| 12 | the IMSI that their ME is sending. |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 13 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 14 | The 3GPP specifications provide means for implementations to send the |
| 15 | IMSI less often by using the Temporary Mobile Subscriber Identity (TMSI) |
| 16 | where possible. However, the decision on when to use IMSI or TMSI is |
| 17 | entirely on the networks side, without any control by the ME or even the |
| 18 | subscriber. |
| 19 | |
| 20 | This leads to a variety of attacks on subscriber location privacy, including |
| 21 | the use of passive air-interface sniffing as well as false base station |
| 22 | attacks, where an attacker impersonates a base station which |
| 23 | subsequently inquires every ME about its IMSI. |
| 24 | |
| 25 | Some related devices have been termed _IMSI catchers_ or _Stingray_ in |
| 26 | both scientific literature as well as mainstream media. IMSI catchers have |
| 27 | become small and affordable during the last decade; criminals actors |
| 28 | and in some cases even tabloid journalists without much budget have |
| 29 | reportedly used them to track anybody with a mobile phone. |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 30 | |
Oliver Smith | efe5c98 | 2020-04-15 10:29:21 +0200 | [diff] [blame] | 31 | 5G addresses this problem with the Subscriber Concealed Identifier (SUCI), |
| 32 | which uses public-key cryptography to ensure that the permanent subscriber |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 33 | identity (IMSI) is not transmitted over the air interface anymore. |
| 34 | Rather, a concealed version of it is transmitted (3GPP TS 33.501, |
Harald Welte | 29a79af | 2020-04-16 12:23:34 +0200 | [diff] [blame] | 35 | Section 6.12.2). The 5G SUCI mechanism can not be adapted easily for previous |
| 36 | generations of cellular networks as it relies on introducing an entirely |
| 37 | new mobile identity type of larger size (SUCI) than any of the existing |
| 38 | ones (e.g. IMSI), causing significant implications on protocol stacks |
| 39 | and implementations all across the protocol stack of all network elements, |
| 40 | including the ME. |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 41 | |
| 42 | No mechanism for increasing subscriber identity and location privacy on |
| 43 | the radio interface has been specified for the previous cellular |
| 44 | technologies 2G (GSM), 3G (UMTS) and 4G (LTE). Meanwhile, pure 5G |
| 45 | networks are and will remain rare for many years to come, as operators |
| 46 | have to support billions of deployed legacy pre-5G ME. Operating |
| 47 | combined 5G + previous technology networks enables the so-called |
| 48 | "downgrade attacks" where the attacker blocks access to 5G e.g. by means |
| 49 | of jamming/interference, and hence triggers the ME to use a previous |
| 50 | generation which is still susceptible to the attacks. |
| 51 | |
| 52 | This specification proposes a different approach to conceal the |
| 53 | IMSI for legacy 2G, 3G and 4G networks. |
Oliver Smith | efe5c98 | 2020-04-15 10:29:21 +0200 | [diff] [blame] | 54 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 55 | === Summary of Proposed Solution |
| 56 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 57 | The solution presented in this document is to periodically change the IMSI of |
| 58 | the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR) |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 59 | or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM/USIM |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 60 | via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 61 | SIM/USIM with the new value. The only components in the network that need to be |
| 62 | changed in order to support this mechanism are the SIM/USIM and the |
| 63 | HLR/HSS. All other elements (like BTS, NodeB, eNodeB, BSC, RNC, MME, |
| 64 | MSC/VLR, SGSN, GGSN, S-GW, P-GW, ...) remain as-is, without any changes |
| 65 | to their specification or implementation. |
| 66 | |
| 67 | Constraining the required changes to only two elements in the network |
| 68 | enables quick adoption potential for the proposed mechanism. |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 69 | Furthermore, as SIM/USIM and HLR/HSS are the only two elements under control |
| 70 | of a Mobile Virtual Network Operator (MVNO), this mechanism can be |
| 71 | deployed by a MVNO without any changes to the operators of the physical |
| 72 | infrastructure (MNO). |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 73 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 74 | <<< |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 75 | === Summary of Existing Location Updating Procedures in RAN and CN |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 76 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 77 | Every subscriber's SIM/USIM is provisioned with the IMSI and secret |
| 78 | cryptographic keys (Ki or K+OP[c]). The same IMSI and key data is also provisioned |
| 79 | into the HLR/HSS, the central subscriber database of a cellular network. |
| 80 | |
| 81 | In a number of different situations, the IMSI is sent over the air |
| 82 | interface and back-haul towards the Core Network (CN), where it is |
| 83 | validated by the HLR/HSS. The involved components vary by the generation |
| 84 | of the network and whether the SIM/USIM is attempting a Circuit Switched (CS) |
| 85 | or Packet Switched (PS) connection, but the principle is the same. This |
| 86 | document uses 2G CS Location Updating for reference, as in |
| 87 | <<figure-imsi-regular>>. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 88 | |
| 89 | The IMSI is transmitted in the Location Updating Request from ME. The VLR |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 90 | needs an authentication challenge specific to the secret keys on the SIM/USIM to |
| 91 | authenticate the SIM/USIM, and looks the authentication challenges up by the IMSI. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 92 | If the VLR does not have any more authentication challenges for the IMSI (as it |
| 93 | happens when the VLR sees the IMSI for the first time), the VLR requests new |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 94 | authentication challenges from the HLR/HSS. Then the HLR/HSS verifies that the IMSI is |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 95 | known and, if it is unknown, sends back an error that will terminate the |
| 96 | Location Updating procedure. |
| 97 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 98 | After the VLR found the authentication challenge, it authenticates the SIM/USIM, and |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 99 | performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR |
| 100 | has the required information to finish the Location Updating, and continues |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 101 | with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns |
| 102 | a new TMSI with the Location Updating Accept, which is acknowledged by the TMSI |
| 103 | Reallocation Complete. In following Location Updates with the same MSC, the ME |
| 104 | sends the TMSI instead of the IMSI in the Location Updating Request. |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 105 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 106 | However, the allocation of the TMSI is optional (the network may choose |
| 107 | to not perform it), and particularly at mobility changes across the |
| 108 | MSC/VLR boundary, or even across the PLMN boundary, the TMSI allocated |
| 109 | by the previouis network element may not be known, and an IMSI based |
Oliver Smith | e87abdf | 2020-04-16 11:18:20 +0200 | [diff] [blame] | 110 | Location Updating procedure is used. |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 111 | |
| 112 | Furthermore, at any given point in time, a legitimate network or a rogue |
| 113 | base station can inquire the IMSI from the ME using the "MM IDENTITY |
| 114 | REQUEST (IMSI)" command. |
| 115 | |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 116 | [[figure-imsi-regular]] |
| 117 | .Location Updating in 2G CS with IMSI |
| 118 | ["mscgen"] |
| 119 | ---- |
| 120 | msc { |
| 121 | hscale="1.75"; |
| 122 | ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"], |
| 123 | HLR [label="HLR"]; |
| 124 | |
| 125 | // BTS <=> BSC: RSL |
| 126 | // BSC <=> MSC: BSSAP, RNSAP |
| 127 | // MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002) |
| 128 | |
| 129 | ME => BTS [label="Location Updating Request"]; |
| 130 | BTS => BSC [label="Location Updating Request"]; |
| 131 | BSC => MSC [label="Location Updating Request"]; |
| 132 | |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 133 | --- [label="If necessary: VLR requests new authentication challenges for this IMSI"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 134 | MSC => HLR [label="Send Auth Info Request"]; |
| 135 | MSC <= HLR [label="Send Auth Info Result"]; |
| 136 | ---; |
| 137 | |
| 138 | BSC <= MSC [label="Authentication Request"]; |
| 139 | BTS <= BSC [label="Authentication Request"]; |
| 140 | ME <= BTS [label="Authentication Request"]; |
| 141 | ME => BTS [label="Authentication Response"]; |
| 142 | BTS => BSC [label="Authentication Response"]; |
| 143 | BSC => MSC [label="Authentication Response"]; |
| 144 | BSC <= MSC [label="Classmark Enquiry"]; |
| 145 | BTS <= BSC [label="Classmark Enquiry"]; |
| 146 | ME <= BTS [label="Classmark Enquiry"]; |
| 147 | ME => BTS [label="Classmark Change"]; |
| 148 | BTS => BSC [label="Classmark Change"]; |
| 149 | BSC => MSC [label="Classmark Update"]; |
| 150 | BSC <= MSC [label="Physical Channel Reconfiguration"]; |
| 151 | BTS <= BSC [label="Ciphering Mode Command"]; |
| 152 | ME <= BTS [label="Ciphering Mode Command"]; |
Oliver Smith | 8c81b55 | 2020-04-07 08:44:56 +0200 | [diff] [blame] | 153 | ME => BTS [label="Ciphering Mode Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 154 | BTS => BSC [label="Ciphering Mode Complete"]; |
| 155 | BSC => MSC [label="Ciphering Mode Complete"]; |
| 156 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 157 | --- [label="Process Update_Location_HLR (3GPP TS 29.002)"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 158 | MSC => HLR [label="Update Location Request"]; |
| 159 | MSC <= HLR [label="Insert Subscriber Data Request"]; |
| 160 | MSC => HLR [label="Insert Subscriber Data Result"]; |
| 161 | MSC <= HLR [label="Update Location Result"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 162 | ---; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 163 | |
| 164 | BSC <= MSC [label="Location Updating Accept"]; |
| 165 | BTS <= BSC [label="Location Updating Accept"]; |
| 166 | ME <= BTS [label="Location Updating Accept"]; |
| 167 | ME => BTS [label="TMSI Reallocation Complete"]; |
| 168 | BTS => BSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 169 | BSC => MSC [label="TMSI Reallocation Complete"]; |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 170 | } |
| 171 | ---- |
| 172 | |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 173 | <<< |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 174 | == Required Changes |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 175 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 176 | This section covers the changes / enhancements required |
| 177 | compared to the existing 3GPP specifications. |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 178 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 179 | [[hlr-imsi-pseudo-storage]] |
| 180 | === Pseudonymous IMSI Storage in the HLR/HSS |
| 181 | |
| 182 | The HLR/HSS must store up to two pseudonymous IMSIs (`imsi_pseudo`) and |
| 183 | their related counters (`imsi_pseudo_i`) per subscriber. Each subscriber |
| 184 | initially has one pseudonymous IMSI allocated. A subscriber has two |
| 185 | valid pseudonymous IMSIs only during the transition phase from the old |
| 186 | pseudonymous IMSI to the new one. |
| 187 | |
| 188 | Subsequently, the amount of available IMSIs must be higher than the |
| 189 | amount of subscribers registered with the HLR/HSS. If the amount of |
| 190 | available IMSIs is too small, the HLR/HSS could delay assigning new |
| 191 | pseudonymous IMSIs until new IMSIs are available again. |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 192 | |
| 193 | .Examples for additional subscriber data in HLR |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 194 | [options="header"] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 195 | |=== |
| 196 | | Subscriber ID | imsi_pseudo | imsi_pseudo_i |
| 197 | // example IMSIs taken from Wikipedia |
| 198 | | 123 |
| 199 | | 310150123456789 |
| 200 | | 1 |
| 201 | |
| 202 | | 234 |
| 203 | | 502130123456789 |
| 204 | | 1 |
| 205 | |
| 206 | | 234 |
| 207 | | 460001357924680 |
| 208 | | 2 |
| 209 | |=== |
| 210 | |
| 211 | ==== imsi_pseudo |
| 212 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 213 | The value for `imsi_pseudo` is a random choice from the pool of available |
| 214 | IMSIs that the HLR/HSS controls. The pseudonymous IMSI must not be used |
| 215 | by any subscriber as pseudonymous IMSI yet, but may be the real IMSI of |
| 216 | a subscriber. |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 217 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 218 | [[hlr-imsi-pseudo-i]] |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 219 | ==== imsi_pseudo_i |
| 220 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 221 | The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI |
Oliver Smith | 8c81b55 | 2020-04-07 08:44:56 +0200 | [diff] [blame] | 222 | was changed. The value is 1 for the first allocated pseudonymous IMSI of a |
| 223 | subscriber. When allocating a new pseudonymous IMSI for the same subscriber, |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 224 | the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 225 | applet to detect and ignore outdated requests related to changing the |
| 226 | pseudonymous IMSI. |
| 227 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 228 | <<< |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 229 | === SIM/USIM Provisioning |
Oliver Smith | 6f9f218 | 2020-04-06 14:29:34 +0200 | [diff] [blame] | 230 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 231 | IMSI pseudonymization as specified by this document works with |
Oliver Smith | e87abdf | 2020-04-16 11:18:20 +0200 | [diff] [blame] | 232 | traditional SIM (used in 2G), as well as with USIM (used from 3G |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 233 | onwards). |
| 234 | |
| 235 | The initial IMSI provisioned in the SIM/USIM is provisioned as the initial |
| 236 | pseudonymous IMSI in the HLR/HSS. |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 237 | |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 238 | [[sim-app]] |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 239 | ==== SIM applet |
| 240 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 241 | SIM/USIM have long supported the installation and operation of |
| 242 | additional applets on the card itself. The programming language and |
| 243 | runtime environment for such applets is an implementation detail. |
| 244 | However, the industry has converged around JavaCards with related |
| 245 | additional APIs specific to SIM, UICC and USIM. Depending on the card |
| 246 | profile / provisioning, it is possible for such applets to access the |
| 247 | card file system and modify files on the card, such as the file storing |
| 248 | the IMSI. |
| 249 | |
| 250 | A SIM/USIM compatible with this specification is provisioned with a SIM |
| 251 | applet, which is able to change the IMSI once the next pseudonymous IMSI |
| 252 | arrives from the HLR/HSS. A reference implementation is provided in |
| 253 | <<reference-src>>. |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 254 | |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 255 | ===== Counter Storage |
| 256 | |
| 257 | The following counter variables are stored in the SIM applet. |
| 258 | |
| 259 | [options="header",cols="20%,12%,68%"] |
| 260 | |=== |
| 261 | | Name | Initial value | Description |
| 262 | |
| 263 | | imsi_pseudo_i |
| 264 | | 1 |
| 265 | | See <<hlr-imsi-pseudo-i>>. |
| 266 | |
| 267 | | imsi_pseudo_lu |
| 268 | | 0 |
| 269 | | Amount of Location Updating procedures done with the same pseudonymous IMSI. |
| 270 | |
| 271 | | imsi_pseudo_lu_max |
| 272 | | (decided by operator) |
| 273 | | Maximum amount of Location Updating procedures done with the same |
| 274 | pseudonymous IMSI, before the SIM applet shows a warning to the subscriber. |
| 275 | |=== |
| 276 | |
| 277 | ===== Switch to Next Pseudonymous IMSI |
| 278 | |
Harald Welte | 37981b6 | 2020-04-11 10:19:21 +0200 | [diff] [blame] | 279 | The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 280 | 6.2). When an SMS from the HLR/HSS in the structure of <<sms-structure>> arrives, |
| 281 | the applet must verify that the SMS is not outdated by comparing `imsi_pseudo_i` |
| 282 | from the SMS with the last `imsi_pseudo_i` that was used when changing the IMSI |
Oliver Smith | 04ff01e | 2020-05-08 08:54:27 +0200 | [diff] [blame] | 283 | (initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher. The |
| 284 | SIM applet must also verify, that the pseudonymous IMSI arriving in the SMS is |
| 285 | different from the currently active IMSI. If any of the checks fail, the SMS |
| 286 | must not be processed further. |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 287 | |
Oliver Smith | e87abdf | 2020-04-16 11:18:20 +0200 | [diff] [blame] | 288 | The SIM applet registers a timer with `min_sleep_time` from the SMS. When the |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 289 | timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous |
Oliver Smith | b80a9f8 | 2020-04-15 11:46:36 +0200 | [diff] [blame] | 290 | IMSI. The TMSI and related data (EF~LOCI~, EF~PSLOCI~) and ciphering keys |
| 291 | (EF~Kc~, EF~KcGPRS~, EF~Keys~, EF~KeysPS~) are invalidated (see 3GPP TS |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 292 | 31.102). The current `imsi_pseudo_i` from the SMS is stored in the |
| 293 | SIM applet to compare it with the next SMS. `imsi_pseudo_lu` is reset to 0. Afterwards, |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 294 | the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed |
| 295 | to apply the new IMSI. |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 296 | |
| 297 | // FIXME: do we need to enforce the LU now, with an arbitrary CM Service |
| 298 | // Request, or would this only be necessary for Osmocom? (OS#4404) |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 299 | |
| 300 | ===== Warning the Subscriber If the Pseudonymous IMSI Does Not Change |
| 301 | |
| 302 | An attacker could potentially block the next pseudonymous IMSI SMS on purpose. |
| 303 | Because the SIM applet cannot decide the next pseudonymous IMSI, it would have |
| 304 | the same pseudonymous IMSI for a long time. Then it could become feasible for |
| 305 | an attacker to track the subscriber by their pseudonymous IMSI. Therefore the |
Oliver Smith | 4d3277f | 2020-05-08 09:42:11 +0200 | [diff] [blame^] | 306 | SIM applet must warn the subscriber if the pseudonymous IMSI does not change. |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 307 | |
| 308 | The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 309 | 03.19, Section 6.2) and increases `imsi_pseudo_lu` by 1 when the event is |
| 310 | triggered. If `imsi_pseudo_lu` reaches `imsi_pseudo_lu_max`, the SIM applet |
Oliver Smith | 69e3fa6 | 2020-04-09 14:54:49 +0200 | [diff] [blame] | 311 | displays a warning to the subscriber. |
| 312 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 313 | <<< |
Oliver Smith | bb8d912 | 2020-04-08 14:58:50 +0200 | [diff] [blame] | 314 | [[process-update-location-hlr]] |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 315 | === Process Update_Location_HLR |
Oliver Smith | bf33c75 | 2020-04-06 15:46:29 +0200 | [diff] [blame] | 316 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 317 | All IMSI Pseudonymization related changes to Process Update_Location_HLR |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 318 | (3GPP TS 29.002) are optional. Deviations from the existing specification that |
| 319 | are outlined in this section are expected to be enabled or disabled entirely |
| 320 | where IMSI pseudonymization is implemented. |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 321 | |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 322 | [[figure-imsi-pseudo]] |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 323 | .Process Update_Location_HLR with IMSI pseudonymization changes |
| 324 | ["mscgen"] |
| 325 | ---- |
| 326 | msc { |
| 327 | hscale="1.75"; |
| 328 | MSC [label="MSC/VLR"], SMSC [label="SMS-SC"], HLR [label="HLR"]; |
| 329 | |
| 330 | MSC => HLR [label="Update Location Request"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 331 | |
| 332 | --- [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] | 333 | HLR box HLR [label="Deallocate old pseudonymous IMSI"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 334 | MSC <= HLR [label="Cancel Location Request"]; |
| 335 | MSC => HLR [label="Cancel Location Result"]; |
| 336 | ---; |
| 337 | |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 338 | MSC <= HLR [label="Insert Subscriber Data Request"]; |
| 339 | MSC => HLR [label="Insert Subscriber Data Result"]; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 340 | HLR box HLR [label="Start Next_Pseudo_IMSI_Timer"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 341 | MSC <= HLR [label="Update Location Result"]; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 342 | MSC box MSC [label="Finish Location Updating with ME"], |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 343 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 344 | HLR box HLR [label="Wait for Next_Pseudo_IMSI_Timer expiry"]; |
Oliver Smith | 206a0fa | 2020-04-07 14:30:07 +0200 | [diff] [blame] | 345 | |||; |
| 346 | ...; |
| 347 | |||; |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 348 | HLR box HLR [label="Next_Pseudo_IMSI_Timer expired"]; |
Oliver Smith | 7e33ef5 | 2020-04-07 15:05:11 +0200 | [diff] [blame] | 349 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 350 | 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] | 351 | SMSC <= HLR [label="Next Pseudonymous IMSI SMS"]; |
| 352 | SMSC box SMSC [label="Deliver SMS to ME"]; |
| 353 | } |
| 354 | ---- |
Oliver Smith | 7afd701 | 2020-04-06 11:59:59 +0200 | [diff] [blame] | 355 | |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 356 | ==== Update Location Request |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 357 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 358 | When Update Location Request arrives, the HLR/HSS does not look up the subscriber |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 359 | 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] | 360 | two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the |
| 361 | Update Location Request, this is followed by the existing logic to continue |
| 362 | with Insert Subscriber Data Request. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 363 | |
| 364 | ===== Update Location Request With New Pseudonymous IMSI |
| 365 | |
| 366 | If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 367 | used (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), this section applies. |
| 368 | The older pseudonymous IMSI is deallocated in the HLR/HSS. This is done as early |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 369 | as possible, so the timeframe where two pseudonymous IMSI are allocated for one |
| 370 | subscriber is short. |
| 371 | |
| 372 | A Cancel Location Request with the old pseudonymous IMSI is sent to the VLR, so |
| 373 | the conflicting subscriber entry with the old pseudonymous IMSI is deleted from |
| 374 | the VLR. Receiving a Cancel Location Result is followed by the existing logic |
| 375 | to continue with Insert Subscriber Data Request. |
| 376 | |
| 377 | ===== Update Location Request With Old Pseudonymous IMSI |
| 378 | |
| 379 | If the subscriber has two pseudonymous IMSIs allocated, and the older entry was |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 380 | used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_ |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 381 | deallocated. This could lock out the subscriber from the network if the SMS |
| 382 | with the new pseudonymous IMSI arrives with a delay. |
| 383 | |
| 384 | ==== Insert Subscriber Data Result |
| 385 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 386 | When Insert Subscriber Data Result arrives, a subscriber specific |
| 387 | Next_Pseudo_IMSI_Timer starts. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 388 | |
Oliver Smith | fcf7811 | 2020-05-08 09:35:34 +0200 | [diff] [blame] | 389 | [[next-pseudo-imsi-timer-expires]] |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 390 | ==== Next_Pseudo_IMSI_Timer Expires |
| 391 | |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 392 | If the subscriber has only one pseudonymous IMSI allocated, and the amount of |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 393 | available IMSIs in the HLR/HSS is high enough, a second pseudonymous IMSI and |
| 394 | related `imsi_pseudo_i` gets allocated for the subscriber (as described in |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 395 | <<hlr-imsi-pseudo-storage>>). |
| 396 | |
| 397 | If the subscriber still has only one pseudonymous IMSI, because not enough |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 398 | IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 399 | a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 400 | new pseudonymous IMSI during the next Location Updating Procedure, if |
| 401 | the HLR/HSS has enough IMSIs available at that point. |
Oliver Smith | 64d154c | 2020-04-08 08:36:18 +0200 | [diff] [blame] | 402 | |
| 403 | An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 404 | IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related |
| 405 | `imsi_pseudo_i` value. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 406 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 407 | [[sms-structure]] |
| 408 | ==== Next Pseudonymous IMSI SMS Structure |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 409 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 410 | .Next pseudonymous IMSI SMS structure |
| 411 | [packetdiag] |
| 412 | ---- |
| 413 | { |
| 414 | colwidth = 32 |
| 415 | |
| 416 | 0-31: IMSI_PSEUDO_I |
| 417 | 32-63: MIN_SLEEP_TIME |
| 418 | 64-119: IMSI_PSEUDO |
| 419 | 120-127: PAD |
| 420 | } |
| 421 | ---- |
| 422 | |
Oliver Smith | a0354de | 2020-04-09 15:13:38 +0200 | [diff] [blame] | 423 | // FIXME |
| 424 | IMPORTANT: This is a draft. The structure is likely to change after the |
| 425 | reference implementation phase. |
| 426 | |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 427 | IMSI_PSEUDO_I: 32 bits:: |
| 428 | See <<hlr-imsi-pseudo-i>>. |
| 429 | |
| 430 | MIN_SLEEP_TIME: 32 bits:: |
Oliver Smith | 4d3277f | 2020-05-08 09:42:11 +0200 | [diff] [blame^] | 431 | Amount of seconds, which the SIM applet must wait before changing to the new |
Oliver Smith | 7b0dbb9 | 2020-04-08 10:33:52 +0200 | [diff] [blame] | 432 | pseudonymous IMSI. Since it is unclear when the SMS will arrive (ME might be |
| 433 | turned off), this is a minimum amount. |
| 434 | |
| 435 | IMSI_PSEUDO: 60 bits:: |
| 436 | Telephony Binary Coded Decimal (TBCD, 3GPP TS 29.002) version of the next |
| 437 | pseudonymous IMSI. |
| 438 | |
| 439 | PAD: 8 bits:: |
Oliver Smith | 4d3277f | 2020-05-08 09:42:11 +0200 | [diff] [blame^] | 440 | Padding at the end, must be filled with 1111 as in the TBCD specification. |
Oliver Smith | ef43ac3 | 2020-04-07 16:02:19 +0200 | [diff] [blame] | 441 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 442 | <<< |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 443 | == Error Scenarios |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 444 | |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 445 | === Next Pseudonymous IMSI SMS is Lost |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 446 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 447 | If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 448 | the next Location Updating Procedure with the old pseudonymous IMSI. Because |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 449 | the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point, |
Oliver Smith | fcf7811 | 2020-05-08 09:35:34 +0200 | [diff] [blame] | 450 | the subscriber is not locked out of the network. The HLR/HSS does not deallocate |
| 451 | the new pseudonymous IMSI that did not arrive, but instead send it again |
| 452 | (<<next-pseudo-imsi-timer-expires>>). |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 453 | |
Oliver Smith | a281464 | 2020-04-14 14:31:29 +0200 | [diff] [blame] | 454 | === Next Pseudonymous IMSI SMS Arrives Out of Order |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 455 | |
| 456 | The next pseudonymous IMSI SMS may arrive out of order. Either, because the |
| 457 | network is not able to deliver them in order, or even because an attacker would |
| 458 | perform a replay attack. |
| 459 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 460 | If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher |
Oliver Smith | 5de45c0 | 2020-04-08 14:37:58 +0200 | [diff] [blame] | 461 | than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet |
| 462 | 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] | 463 | |
Oliver Smith | 8b68e4e | 2020-04-07 09:38:49 +0200 | [diff] [blame] | 464 | // === SMS Arrives Before Timer Expires |
| 465 | // FIXME: OS#4486 |
| 466 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 467 | <<< |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 468 | == Recommendations for Real-World Implementations |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 469 | |
Oliver Smith | 18bf9bb | 2020-04-08 15:26:59 +0200 | [diff] [blame] | 470 | === BCCH SI3: ATT = 0 |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 471 | |
Oliver Smith | 18bf9bb | 2020-04-08 15:26:59 +0200 | [diff] [blame] | 472 | When changing from one pseudonymous IMSI to the next, it is important that the |
| 473 | ME does not detach from the network. Otherwise it would be trivial for an |
| 474 | attacker to correlate the detach with the attach of the same ME with the next |
| 475 | pseudonymous IMSI. |
| 476 | |
| 477 | This is controlled with the ATT flag in the SYSTEM INFORMATION TYPE 3 (SI3) |
| 478 | message on the Broadcast Control Channel (BCCH), see 3GPP TS 44.018 Section |
| 479 | 10.5.2.11. It must be set to 0. |
| 480 | |
| 481 | // FIXME: verify how it set with operators in germany (OS#4404) |
| 482 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 483 | === End to End Encryption of SMS |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 484 | |
Oliver Smith | 4d3277f | 2020-05-08 09:42:11 +0200 | [diff] [blame^] | 485 | When deploying the IMSI pseudonymization, the operator must make sure that |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 486 | the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified |
| 487 | by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 488 | pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 489 | network. |
| 490 | |
| 491 | The safest way to protect the next pseudonymous IMSI SMS is a layer of end to |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 492 | end encryption from the HLR/HSS to the SIM/USIM. The existing means for OTA SMS |
Oliver Smith | a281464 | 2020-04-14 14:31:29 +0200 | [diff] [blame] | 493 | security (3GPP TS 23.048) provide mechanisms for integrity protection, |
| 494 | confidentiality as well as replay protection and must be implemented when using |
| 495 | IMSI pseudonymization. |
Oliver Smith | cbe9058 | 2020-04-08 15:38:29 +0200 | [diff] [blame] | 496 | |
Oliver Smith | 5c95bc9 | 2020-04-03 14:03:24 +0200 | [diff] [blame] | 497 | === User-configurable Minimum Duration Between IMSI Changes |
Oliver Smith | 2c8a19c | 2020-04-06 14:04:13 +0200 | [diff] [blame] | 498 | |
Oliver Smith | a0354de | 2020-04-09 15:13:38 +0200 | [diff] [blame] | 499 | It may be desirable to let subscribers configure their minimum duration between |
| 500 | IMSI changes. This allows subscribers with a high privacy requirement to switch |
| 501 | their pseudonymous IMSI more often, and it allows the pseudonymous IMSI change |
| 502 | to happen less frequently if it is distracting to the subscriber. |
| 503 | |
| 504 | How distracting the pseudonymous IMSI change is, depends on the ME. The |
| 505 | following examples were observed: |
| 506 | |
| 507 | // FIXME: might need an update after SYS#4481 |
| 508 | |
| 509 | * A Samsung GT-I9100 Galaxy SII smartphone with Android 4.0.3 displays a |
| 510 | message at the bottom of the screen for about 5 seconds, but the user |
| 511 | interface remains usable. |
| 512 | * A Samsung GT-E1200 feature phone displays a waiting screen for 16 to 17 |
| 513 | seconds and is unusable during that time. |
| 514 | |
Oliver Smith | 968dd35 | 2020-04-16 11:34:01 +0200 | [diff] [blame] | 515 | <<< |
Oliver Smith | 0feaa89 | 2020-04-09 15:15:29 +0200 | [diff] [blame] | 516 | [[reference-src]] |
| 517 | == Reference Implementation with Source Code |
| 518 | |
| 519 | A reference implementation for the SIM applet (<<sim-app>>) is available in |
| 520 | source code under the Apache-2.0 license at: |
| 521 | |
| 522 | https://osmocom.org/projects/imsi-pseudo |
| 523 | |
Harald Welte | 9db94bb | 2020-04-16 10:36:19 +0200 | [diff] [blame] | 524 | The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and |
Oliver Smith | 0feaa89 | 2020-04-09 15:15:29 +0200 | [diff] [blame] | 525 | <<process-update-location-hlr>> were implemented for reference in OsmoHLR from |
| 526 | the Osmocom project, licensed under AGPL-3.0. Information about the source code |
| 527 | and related branches for IMSI pseudonymization can be found at the above URL as |
| 528 | well. |