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