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 for cellular mobile
|
8
|
communications starting from 2G (GSM) is, that mobile phones and
|
9
|
other mobile equipment (ME) have to send the International Mobile Subscriber
|
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.
|
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
|
|
31
|
5G addresses this problem with the Subscriber Concealed Identifier (SUCI),
|
32
|
which uses public-key cryptography to ensure that the permanent subscriber
|
33
|
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 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.
|
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.
|
54
|
|
55
|
=== Summary of Proposed Solution
|
56
|
|
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)
|
59
|
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM/USIM
|
60
|
via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the
|
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.
|
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).
|
73
|
|
74
|
<<<
|
75
|
=== Summary of Existing Location Updating Procedures in RAN and CN
|
76
|
|
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>>.
|
88
|
|
89
|
The IMSI is transmitted in the Location Updating Request from ME. The VLR
|
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.
|
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
|
94
|
authentication challenges from the HLR/HSS. Then the HLR/HSS verifies that the IMSI is
|
95
|
known and, if it is unknown, sends back an error that will terminate the
|
96
|
Location Updating procedure.
|
97
|
|
98
|
After the VLR found the authentication challenge, it authenticates the SIM/USIM, and
|
99
|
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
100
|
has the required information to finish the Location Updating, and continues
|
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.
|
105
|
|
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
|
110
|
Location Updating procedure is used.
|
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
|
|
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
|
|
133
|
--- [label="If necessary: VLR requests new authentication challenges for this IMSI"];
|
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"];
|
153
|
ME => BTS [label="Ciphering Mode Complete"];
|
154
|
BTS => BSC [label="Ciphering Mode Complete"];
|
155
|
BSC => MSC [label="Ciphering Mode Complete"];
|
156
|
|
157
|
--- [label="Process Update_Location_HLR (3GPP TS 29.002)"];
|
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"];
|
162
|
---;
|
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"];
|
169
|
BSC => MSC [label="TMSI Reallocation Complete"];
|
170
|
}
|
171
|
----
|
172
|
|
173
|
<<<
|
174
|
== Required Changes
|
175
|
|
176
|
This section covers the changes / enhancements required
|
177
|
compared to the existing 3GPP specifications.
|
178
|
|
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.
|
192
|
|
193
|
.Examples for additional subscriber data in HLR
|
194
|
[options="header"]
|
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
|
|
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.
|
217
|
|
218
|
[[hlr-imsi-pseudo-i]]
|
219
|
==== imsi_pseudo_i
|
220
|
|
221
|
The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI
|
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,
|
224
|
the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM
|
225
|
applet to detect and ignore outdated requests related to changing the
|
226
|
pseudonymous IMSI.
|
227
|
|
228
|
<<<
|
229
|
=== SIM/USIM Provisioning
|
230
|
|
231
|
IMSI pseudonymization as specified by this document works with
|
232
|
traditional SIM (used in 2G), as well as with USIM (used from 3G
|
233
|
onwards).
|
234
|
|
235
|
The initial IMSI provisioned in the SIM/USIM is provisioned as the initial
|
236
|
pseudonymous IMSI in the HLR/HSS.
|
237
|
|
238
|
[[sim-app]]
|
239
|
==== SIM applet
|
240
|
|
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>>.
|
254
|
|
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
|
|
279
|
The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section
|
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
|
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.
|
287
|
|
288
|
The SIM applet registers a timer with `min_sleep_time` from the SMS. When the
|
289
|
timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous
|
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
|
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,
|
294
|
the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed
|
295
|
to apply the new IMSI.
|
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)
|
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
|
306
|
SIM applet must warn the subscriber if the pseudonymous IMSI does not change.
|
307
|
|
308
|
The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS
|
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
|
311
|
displays a warning to the subscriber.
|
312
|
|
313
|
<<<
|
314
|
[[process-update-location-hlr]]
|
315
|
=== Process Update_Location_HLR
|
316
|
|
317
|
All IMSI Pseudonymization related changes to Process Update_Location_HLR
|
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.
|
321
|
|
322
|
[[figure-imsi-pseudo]]
|
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"];
|
331
|
|
332
|
--- [label="If new pseudonymous IMSI was used: deallocate and cancel old pseudonymous IMSI"];
|
333
|
HLR box HLR [label="Deallocate old pseudonymous IMSI"];
|
334
|
MSC <= HLR [label="Cancel Location Request"];
|
335
|
MSC => HLR [label="Cancel Location Result"];
|
336
|
---;
|
337
|
|
338
|
MSC <= HLR [label="Insert Subscriber Data Request"];
|
339
|
MSC => HLR [label="Insert Subscriber Data Result"];
|
340
|
HLR box HLR [label="Start Next_Pseudo_IMSI_Timer"];
|
341
|
MSC <= HLR [label="Update Location Result"];
|
342
|
MSC box MSC [label="Finish Location Updating with ME"],
|
343
|
|
344
|
HLR box HLR [label="Wait for Next_Pseudo_IMSI_Timer expiry"];
|
345
|
|||;
|
346
|
...;
|
347
|
|||;
|
348
|
HLR box HLR [label="Next_Pseudo_IMSI_Timer expired"];
|
349
|
|
350
|
HLR box HLR [label="\nAllocate new pseudonymous IMSI\nif subscriber has only one allocated\n"];
|
351
|
SMSC <= HLR [label="Next Pseudonymous IMSI SMS"];
|
352
|
SMSC box SMSC [label="Deliver SMS to ME"];
|
353
|
}
|
354
|
----
|
355
|
|
356
|
==== Update Location Request
|
357
|
|
358
|
When Update Location Request arrives, the HLR/HSS does not look up the subscriber
|
359
|
by the IMSI, but by the pseudonymous IMSI instead. If the subscriber has two
|
360
|
pseudonymous IMSI allocated and used the new pseudonymous IMSI in the Update
|
361
|
Location Request, <<ul-new-pseudo-imsi>> applies. Otherwise, the HLR continues
|
362
|
with the existing Insert Subscriber Data Request logic.
|
363
|
|
364
|
[[ul-new-pseudo-imsi]]
|
365
|
===== Update Location Request With New Pseudonymous IMSI
|
366
|
|
367
|
If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was
|
368
|
used (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), this section applies.
|
369
|
The older pseudonymous IMSI is deallocated in the HLR/HSS. This is done as early
|
370
|
as possible, so the timeframe where two pseudonymous IMSI are allocated for one
|
371
|
subscriber is short.
|
372
|
|
373
|
A Cancel Location Request with the old pseudonymous IMSI is sent to the VLR, so
|
374
|
the conflicting subscriber entry with the old pseudonymous IMSI is deleted from
|
375
|
the VLR. Receiving a Cancel Location Result is followed by the existing logic
|
376
|
to continue with Insert Subscriber Data Request.
|
377
|
|
378
|
===== Update Location Request With Old Pseudonymous IMSI
|
379
|
|
380
|
If the subscriber has two pseudonymous IMSIs allocated, and the older entry was
|
381
|
used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
|
382
|
deallocated. This could lock out the subscriber from the network if the SMS
|
383
|
with the new pseudonymous IMSI arrives with a delay.
|
384
|
|
385
|
==== Insert Subscriber Data Result
|
386
|
|
387
|
When Insert Subscriber Data Result arrives, a subscriber specific
|
388
|
Next_Pseudo_IMSI_Timer starts.
|
389
|
|
390
|
[[next-pseudo-imsi-timer-expires]]
|
391
|
==== Next_Pseudo_IMSI_Timer Expires
|
392
|
|
393
|
If the subscriber has only one pseudonymous IMSI allocated, and the amount of
|
394
|
available IMSIs in the HLR/HSS is high enough, a second pseudonymous IMSI and
|
395
|
related `imsi_pseudo_i` gets allocated for the subscriber (as described in
|
396
|
<<hlr-imsi-pseudo-storage>>).
|
397
|
|
398
|
If the subscriber still has only one pseudonymous IMSI, because not enough
|
399
|
IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with
|
400
|
a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a
|
401
|
new pseudonymous IMSI during the next Location Updating Procedure, if
|
402
|
the HLR/HSS has enough IMSIs available at that point.
|
403
|
|
404
|
An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous
|
405
|
IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related
|
406
|
`imsi_pseudo_i` value.
|
407
|
|
408
|
[[sms-structure]]
|
409
|
==== Next Pseudonymous IMSI SMS Structure
|
410
|
|
411
|
.Next pseudonymous IMSI SMS structure
|
412
|
[packetdiag]
|
413
|
----
|
414
|
{
|
415
|
colwidth = 32
|
416
|
|
417
|
0-31: IMSI_PSEUDO_I
|
418
|
32-63: MIN_SLEEP_TIME
|
419
|
64-119: IMSI_PSEUDO
|
420
|
120-127: PAD
|
421
|
}
|
422
|
----
|
423
|
|
424
|
// FIXME
|
425
|
IMPORTANT: This is a draft. The structure is likely to change after the
|
426
|
reference implementation phase.
|
427
|
|
428
|
IMSI_PSEUDO_I: 32 bits::
|
429
|
See <<hlr-imsi-pseudo-i>>.
|
430
|
|
431
|
MIN_SLEEP_TIME: 32 bits::
|
432
|
Amount of seconds, which the SIM applet must wait before changing to the new
|
433
|
pseudonymous IMSI. Since it is unclear when the SMS will arrive (ME might be
|
434
|
turned off), this is a minimum amount.
|
435
|
|
436
|
IMSI_PSEUDO: 60 bits::
|
437
|
Telephony Binary Coded Decimal (TBCD, 3GPP TS 29.002) version of the next
|
438
|
pseudonymous IMSI.
|
439
|
|
440
|
PAD: 8 bits::
|
441
|
Padding at the end, must be filled with 1111 as in the TBCD specification.
|
442
|
|
443
|
<<<
|
444
|
== Error Scenarios
|
445
|
|
446
|
=== Next Pseudonymous IMSI SMS is Lost
|
447
|
|
448
|
If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start
|
449
|
the next Location Updating Procedure with the old pseudonymous IMSI. Because
|
450
|
the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point,
|
451
|
the subscriber is not locked out of the network. The HLR/HSS does not deallocate
|
452
|
the new pseudonymous IMSI that did not arrive, but instead send it again
|
453
|
(<<next-pseudo-imsi-timer-expires>>).
|
454
|
|
455
|
=== Next Pseudonymous IMSI SMS Arrives Out of Order
|
456
|
|
457
|
The next pseudonymous IMSI SMS may arrive out of order. Either, because the
|
458
|
network is not able to deliver them in order, or even because an attacker would
|
459
|
perform a replay attack.
|
460
|
|
461
|
If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher
|
462
|
than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet
|
463
|
will discard the message and the subscriber is not locked out of the network.
|
464
|
|
465
|
// === SMS Arrives Before Timer Expires
|
466
|
// FIXME: OS#4486
|
467
|
|
468
|
<<<
|
469
|
== Recommendations for Real-World Implementations
|
470
|
|
471
|
=== BCCH SI3: ATT = 0
|
472
|
|
473
|
When changing from one pseudonymous IMSI to the next, it is important that the
|
474
|
ME does not detach from the network. Otherwise it would be trivial for an
|
475
|
attacker to correlate the detach with the attach of the same ME with the next
|
476
|
pseudonymous IMSI.
|
477
|
|
478
|
This is controlled with the ATT flag in the SYSTEM INFORMATION TYPE 3 (SI3)
|
479
|
message on the Broadcast Control Channel (BCCH), see 3GPP TS 44.018 Section
|
480
|
10.5.2.11. It must be set to 0.
|
481
|
|
482
|
// FIXME: verify how it set with operators in germany (OS#4404)
|
483
|
|
484
|
=== End to End Encryption of SMS
|
485
|
|
486
|
When deploying the IMSI pseudonymization, the operator must make sure that
|
487
|
the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified
|
488
|
by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the
|
489
|
pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the
|
490
|
network.
|
491
|
|
492
|
The safest way to protect the next pseudonymous IMSI SMS is a layer of end to
|
493
|
end encryption from the HLR/HSS to the SIM/USIM. The existing means for OTA SMS
|
494
|
security (3GPP TS 23.048) provide mechanisms for integrity protection,
|
495
|
confidentiality as well as replay protection and must be implemented when using
|
496
|
IMSI pseudonymization.
|
497
|
|
498
|
=== User-configurable Minimum Duration Between IMSI Changes
|
499
|
|
500
|
It may be desirable to let subscribers configure their minimum duration between
|
501
|
IMSI changes. This allows subscribers with a high privacy requirement to switch
|
502
|
their pseudonymous IMSI more often, and it allows the pseudonymous IMSI change
|
503
|
to happen less frequently if it is distracting to the subscriber.
|
504
|
|
505
|
How distracting the pseudonymous IMSI change is, depends on the ME. The
|
506
|
following examples were observed:
|
507
|
|
508
|
// FIXME: might need an update after SYS#4481
|
509
|
|
510
|
* A Samsung GT-I9100 Galaxy SII smartphone with Android 4.0.3 displays a
|
511
|
message at the bottom of the screen for about 5 seconds, but the user
|
512
|
interface remains usable.
|
513
|
* A Samsung GT-E1200 feature phone displays a waiting screen for 16 to 17
|
514
|
seconds and is unusable during that time.
|
515
|
|
516
|
<<<
|
517
|
[[reference-src]]
|
518
|
== Reference Implementation with Source Code
|
519
|
|
520
|
A reference implementation for the SIM applet (<<sim-app>>) is available in
|
521
|
source code under the Apache-2.0 license at:
|
522
|
|
523
|
https://osmocom.org/projects/imsi-pseudo
|
524
|
|
525
|
The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and
|
526
|
<<process-update-location-hlr>> were implemented for reference in OsmoHLR from
|
527
|
the Osmocom project, licensed under AGPL-3.0. Information about the source code
|
528
|
and related branches for IMSI pseudonymization can be found at the above URL as
|
529
|
well.
|