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