Revision 9db94bbf
Added by laforge about 4 years ago
docs/imsi-pseudo-spec.adoc | ||
---|---|---|
4 | 4 |
|
5 | 5 |
=== Protecting the IMSI on the Radio Interface is Desirable |
6 | 6 |
|
7 |
A long-standing issue in the 3GPP specifications is, that mobile phones and |
|
7 |
A long-standing issue in the 3GPP specifications for cellular mobile |
|
8 |
communications starting from 2G (GSM) is, that mobile phones and |
|
8 | 9 |
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. |
|
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. |
|
20 | 30 |
|
21 | 31 |
5G addresses this problem with the Subscriber Concealed Identifier (SUCI), |
22 | 32 |
which uses public-key cryptography to ensure that the permanent subscriber |
23 |
identity can only be read by the home network (3GPP TS 33.501, Section 6.12.2). |
|
24 |
A comparable, but different approach to conceal the IMSI for 2G, 3G and 4G is |
|
25 |
provided in this specification. |
|
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 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. |
|
26 | 52 |
|
27 | 53 |
=== Summary of Proposed Solution |
28 | 54 |
|
29 | 55 |
The solution presented in this document is to periodically change the IMSI of |
30 | 56 |
the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR) |
31 |
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM |
|
57 |
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM/USIM
|
|
32 | 58 |
via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the |
33 |
SIM with the new value. The only component that needs to be changed in the |
|
34 |
network besides the SIM/USIM is the HLR/HSS, therefore it should be possible |
|
35 |
even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy |
|
36 |
enhancement. |
|
59 |
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). |
|
37 | 72 |
|
38 | 73 |
=== Summary of Existing Location Updating Procedures in RAN and CN |
39 | 74 |
|
40 |
The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a |
|
41 |
subscriber, after the subscriber was added with the same data to the HLR/HSS. |
|
42 |
In the Remote Access Network (RAN), the IMSI is sent over the air interface and |
|
43 |
then transmitted to the Core Network (CN), where it is validated by the |
|
44 |
HLR/HSS. The involved components vary by the generation of the network and |
|
45 |
whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS) |
|
46 |
connection, but the principle is the same. This document uses 2G CS Location |
|
47 |
Updating for reference, as in <<figure-imsi-regular>>. |
|
75 |
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>>. |
|
48 | 86 |
|
49 | 87 |
The IMSI is transmitted in the Location Updating Request from ME. The VLR |
50 |
needs an authentication challenge specific to the secret keys on the SIM to |
|
51 |
authenticate the SIM, and looks the authentication challenges up by the IMSI. |
|
88 |
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.
|
|
52 | 90 |
If the VLR does not have any more authentication challenges for the IMSI (as it |
53 | 91 |
happens when the VLR sees the IMSI for the first time), the VLR requests new |
54 |
authentication challenges from the HLR. Then the HLR verifies that the IMSI is
|
|
92 |
authentication challenges from the HLR/HSS. Then the HLR/HSS verifies that the IMSI is
|
|
55 | 93 |
known and, if it is unknown, sends back an error that will terminate the |
56 | 94 |
Location Updating procedure. |
57 | 95 |
|
58 |
After the VLR found the authentication challenge, it authenticates the SIM, and |
|
96 |
After the VLR found the authentication challenge, it authenticates the SIM/USIM, and
|
|
59 | 97 |
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR |
60 | 98 |
has the required information to finish the Location Updating, and continues |
61 | 99 |
with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns |
... | ... | |
63 | 101 |
Reallocation Complete. In following Location Updates with the same MSC, the ME |
64 | 102 |
sends the TMSI instead of the IMSI in the Location Updating Request. |
65 | 103 |
|
104 |
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 |
Location Updating procedure used. |
|
109 |
|
|
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 |
|
|
66 | 114 |
[[figure-imsi-regular]] |
67 | 115 |
.Location Updating in 2G CS with IMSI |
68 | 116 |
["mscgen"] |
... | ... | |
123 | 171 |
<<< |
124 | 172 |
== Required Changes |
125 | 173 |
|
174 |
This section covers the changes / enhancements required |
|
175 |
compared to the existing 3GPP specifications. |
|
176 |
|
|
126 | 177 |
[[hlr-imsi-pseudo-storage]] |
127 |
=== Pseudonymous IMSI Storage in the HLR |
|
178 |
=== 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. |
|
128 | 185 |
|
129 |
The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related |
|
130 |
counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one |
|
131 |
pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs |
|
132 |
only during the transition phase from the old pseudonymous IMSI to the new one. |
|
133 |
The amount of available IMSIs must be higher than the amount of subscribers |
|
134 |
registered with the HLR. If the amount of available IMSIs is too short, the HLR |
|
135 |
can delay assigning new pseudonymous IMSIs until new IMSIs are available again. |
|
186 |
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. |
|
136 | 190 |
|
137 | 191 |
.Examples for additional subscriber data in HLR |
138 | 192 |
[options="header"] |
... | ... | |
154 | 208 |
|
155 | 209 |
==== imsi_pseudo |
156 | 210 |
|
157 |
The value for imsi_pseudo is a random choice from the pool of available IMSIs |
|
158 |
that the HLR controls. The pseudonymous IMSI must not be used by any subscriber |
|
159 |
as pseudonymous IMSI yet, but may be the real IMSI of a subscriber. |
|
211 |
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. |
|
160 | 215 |
|
161 | 216 |
[[hlr-imsi-pseudo-i]] |
162 | 217 |
==== imsi_pseudo_i |
163 | 218 |
|
164 |
The counter imsi_pseudo_i indicates how often a subscribers pseudonymous IMSI
|
|
219 |
The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI
|
|
165 | 220 |
was changed. The value is 1 for the first allocated pseudonymous IMSI of a |
166 | 221 |
subscriber. When allocating a new pseudonymous IMSI for the same subscriber, |
167 |
the new imsi_pseudo_i value is increased by 1. The counter is used by the SIM
|
|
222 |
the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM
|
|
168 | 223 |
applet to detect and ignore outdated requests related to changing the |
169 | 224 |
pseudonymous IMSI. |
170 | 225 |
|
171 |
=== SIM Provisioning |
|
226 |
=== SIM/USIM Provisioning
|
|
172 | 227 |
|
173 |
IMSI pseudonymization as specified by this document works with SIM and USIM. |
|
174 |
The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous |
|
175 |
IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI. |
|
228 |
IMSI pseudonymization as specified by this document works with |
|
229 |
traditional SIM (used i 2G), as well as with USIM (used from 3G |
|
230 |
onwards). |
|
231 |
|
|
232 |
The initial IMSI provisioned in the SIM/USIM is provisioned as the initial |
|
233 |
pseudonymous IMSI in the HLR/HSS. |
|
176 | 234 |
|
177 | 235 |
[[sim-app]] |
178 | 236 |
==== SIM applet |
179 | 237 |
|
180 |
The SIM is provisioned with a SIM applet, which is able to change the IMSI once |
|
181 |
the next pseudonymous IMSI arrives from the HLR. A reference implementation is |
|
182 |
provided in <<reference-src>>. |
|
238 |
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>>. |
|
183 | 251 |
|
184 | 252 |
===== Counter Storage |
185 | 253 |
|
... | ... | |
206 | 274 |
===== Switch to Next Pseudonymous IMSI |
207 | 275 |
|
208 | 276 |
The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section |
209 |
6.2). When an SMS from the HLR in the structure of <<sms-structure>> arrives, |
|
210 |
the applet must verify that the SMS is not outdated by comparing imsi_pseudo_i
|
|
211 |
from the SMS with the last imsi_pseudo_i that was used when changing the IMSI
|
|
277 |
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
|
|
212 | 280 |
(initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher, |
213 | 281 |
otherwise the SMS should not be processed further. |
214 | 282 |
|
215 | 283 |
The SIM applet registers a timer with min_sleep_time from the SMS. When the |
216 |
timer triggers, EF~IMSI~ of the SIM is overwritten with the new pseudonymous |
|
284 |
timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous
|
|
217 | 285 |
IMSI. The TMSI and related data (EF~LOCI~, EF~PSLOCI~) and ciphering keys |
218 | 286 |
(EF~Kc~, EF~KcGPRS~, EF~Keys~, EF~KeysPS~) are invalidated (see 3GPP TS |
219 |
31.102). The current imsi_pseudo_i from the SMS is stored in the SIM applet
|
|
220 |
to compare it with the next SMS. imsi_pseudo_lu is reset to 0. Afterwards,
|
|
287 |
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,
|
|
221 | 289 |
the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed |
222 | 290 |
to apply the new IMSI. |
223 | 291 |
|
... | ... | |
233 | 301 |
SIM applet should warn the subscriber if the pseudonymous IMSI does not change. |
234 | 302 |
|
235 | 303 |
The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS |
236 |
03.19, Section 6.2) and increases imsi_pseudo_lu by 1 when the event is
|
|
237 |
triggered. If imsi_pseudo_lu reaches imsi_pseudo_lu_max, the SIM applet
|
|
304 |
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
|
|
238 | 306 |
displays a warning to the subscriber. |
239 | 307 |
|
240 | 308 |
[[process-update-location-hlr]] |
... | ... | |
281 | 349 |
|
282 | 350 |
==== Update Location Request |
283 | 351 |
|
284 |
When Update Location Request arrives, the HLR does not look up the subscriber |
|
352 |
When Update Location Request arrives, the HLR/HSS does not look up the subscriber
|
|
285 | 353 |
by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has |
286 | 354 |
two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the |
287 | 355 |
Update Location Request, this is followed by the existing logic to continue |
... | ... | |
290 | 358 |
===== Update Location Request With New Pseudonymous IMSI |
291 | 359 |
|
292 | 360 |
If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was |
293 |
used (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), this section applies.
|
|
294 |
The older pseudonymous IMSI is deallocated in the HLR. This is done as early |
|
361 |
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
|
|
295 | 363 |
as possible, so the timeframe where two pseudonymous IMSI are allocated for one |
296 | 364 |
subscriber is short. |
297 | 365 |
|
... | ... | |
303 | 371 |
===== Update Location Request With Old Pseudonymous IMSI |
304 | 372 |
|
305 | 373 |
If the subscriber has two pseudonymous IMSIs allocated, and the older entry was |
306 |
used (lower imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
|
|
374 |
used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
|
|
307 | 375 |
deallocated. This could lock out the subscriber from the network if the SMS |
308 | 376 |
with the new pseudonymous IMSI arrives with a delay. |
309 | 377 |
|
... | ... | |
315 | 383 |
==== Next_Pseudo_IMSI_Timer Expires |
316 | 384 |
|
317 | 385 |
If the subscriber has only one pseudonymous IMSI allocated, and the amount of |
318 |
available IMSIs in the HLR is high enough, a second pseudonymous IMSI and |
|
319 |
related imsi_pseudo_i gets allocated for the subscriber (as described in
|
|
386 |
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
|
|
320 | 388 |
<<hlr-imsi-pseudo-storage>>). |
321 | 389 |
|
322 | 390 |
If the subscriber still has only one pseudonymous IMSI, because not enough |
323 |
IMSIs were available in the HLR, the process is aborted here and no SMS with |
|
391 |
IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with
|
|
324 | 392 |
a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a |
325 |
new pseudonymous IMSI during the next Location Updating Procedure, if the HLR
|
|
326 |
has enough IMSIs available at that point. |
|
393 |
new pseudonymous IMSI during the next Location Updating Procedure, if |
|
394 |
the HLR/HSS has enough IMSIs available at that point.
|
|
327 | 395 |
|
328 | 396 |
An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous |
329 |
IMSI (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>) and related
|
|
330 |
imsi_pseudo_i value.
|
|
397 |
IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related
|
|
398 |
`imsi_pseudo_i` value.
|
|
331 | 399 |
|
332 | 400 |
[[sms-structure]] |
333 | 401 |
==== Next Pseudonymous IMSI SMS Structure |
... | ... | |
368 | 436 |
|
369 | 437 |
=== Next Pseudonymous IMSI SMS is Lost |
370 | 438 |
|
371 |
If the SMS with the next pseudonymous IMSI does not arrive, the SIM will start |
|
439 |
If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start
|
|
372 | 440 |
the next Location Updating Procedure with the old pseudonymous IMSI. Because |
373 |
the HLR has both the old and the new pseudonymous IMSI allocated at this point, |
|
441 |
the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point,
|
|
374 | 442 |
the subscriber is not locked out of the network. |
375 | 443 |
|
376 | 444 |
=== Next Pseudonymous IMSI SMS Arrives Out of Order |
... | ... | |
379 | 447 |
network is not able to deliver them in order, or even because an attacker would |
380 | 448 |
perform a replay attack. |
381 | 449 |
|
382 |
If the SMS arrives out of order, the imsi_pseudo_i counter will not be higher
|
|
450 |
If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher
|
|
383 | 451 |
than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet |
384 | 452 |
will discard the message and the subscriber is not locked out of the network. |
385 | 453 |
|
... | ... | |
406 | 474 |
When deploying the IMSI pseudonymization, the operator should make sure that |
407 | 475 |
the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified |
408 | 476 |
by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the |
409 |
pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the |
|
477 |
pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the
|
|
410 | 478 |
network. |
411 | 479 |
|
412 | 480 |
The safest way to protect the next pseudonymous IMSI SMS is a layer of end to |
413 |
end encryption from the HLR to the SIM. The existing means for OTA SMS
|
|
481 |
end encryption from the HLR/HSS to the SIM/USIM. The existing means for OTA SMS
|
|
414 | 482 |
security (3GPP TS 23.048) provide mechanisms for integrity protection, |
415 | 483 |
confidentiality as well as replay protection and must be implemented when using |
416 | 484 |
IMSI pseudonymization. |
... | ... | |
441 | 509 |
|
442 | 510 |
https://osmocom.org/projects/imsi-pseudo |
443 | 511 |
|
444 |
The HLR modifications described in <<hlr-imsi-pseudo-storage>> and |
|
512 |
The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and
|
|
445 | 513 |
<<process-update-location-hlr>> were implemented for reference in OsmoHLR from |
446 | 514 |
the Osmocom project, licensed under AGPL-3.0. Information about the source code |
447 | 515 |
and related branches for IMSI pseudonymization can be found at the above URL as |
Also available in: Unified diff
spec: Expanding text in some places; language improvements