Revision 69e3fa6b
Added by osmith about 4 years ago
| docs/imsi-pseudo-spec.adoc | ||
|---|---|---|
| 130 | 130 |
can delay assigning new pseudonymous IMSIs until new IMSIs are available again. |
| 131 | 131 |
|
| 132 | 132 |
.Examples for additional subscriber data in HLR |
| 133 |
[options="header"] |
|
| 133 | 134 |
|=== |
| 134 | 135 |
| Subscriber ID | imsi_pseudo | imsi_pseudo_i |
| 135 | 136 |
// example IMSIs taken from Wikipedia |
| ... | ... | |
| 174 | 175 |
the next pseudonymous IMSI arrives from the HLR. A reference implementation is |
| 175 | 176 |
provided in <<reference-src>>. |
| 176 | 177 |
|
| 178 |
===== Counter Storage |
|
| 179 |
|
|
| 180 |
The following counter variables are stored in the SIM applet. |
|
| 181 |
|
|
| 182 |
[options="header",cols="20%,12%,68%"] |
|
| 183 |
|=== |
|
| 184 |
| Name | Initial value | Description |
|
| 185 |
|
|
| 186 |
| imsi_pseudo_i |
|
| 187 |
| 1 |
|
| 188 |
| See <<hlr-imsi-pseudo-i>>. |
|
| 189 |
|
|
| 190 |
| imsi_pseudo_lu |
|
| 191 |
| 0 |
|
| 192 |
| Amount of Location Updating procedures done with the same pseudonymous IMSI. |
|
| 193 |
|
|
| 194 |
| imsi_pseudo_lu_max |
|
| 195 |
| (decided by operator) |
|
| 196 |
| Maximum amount of Location Updating procedures done with the same |
|
| 197 |
pseudonymous IMSI, before the SIM applet shows a warning to the subscriber. |
|
| 198 |
|=== |
|
| 199 |
|
|
| 200 |
===== Switch to Next Pseudonymous IMSI |
|
| 201 |
|
|
| 177 | 202 |
The SIM applet registers to a suitable SMS trigger (3GPP TS 03.19, Section |
| 178 | 203 |
6.2). When an SMS from the HLR in the structure of <<sms-structure>> arrives, |
| 179 | 204 |
the applet must verify that the SMS is not outdated by comparing imsi_pseudo_i |
| ... | ... | |
| 184 | 209 |
The SIM applet registers a timer with min_sleep_time from the SMS. When the |
| 185 | 210 |
timer triggers, the IMSI of the SIM is overwritten with the new pseudonymous |
| 186 | 211 |
IMSI, the TMSI and GSM Ciphering key Kc (3GPP TS 31.102, Section 4.4.3.1) are |
| 187 |
invalidated. The current imsi_pseudo_i value is stored to compare it with the |
|
| 188 |
next SMS. Afterwards, the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section |
|
| 189 |
6.4.7.1 is executed to apply the new IMSI. |
|
| 212 |
invalidated. The current imsi_pseudo_i from the SMS is stored in the SIM applet |
|
| 213 |
to compare it with the next SMS. imsi_pseudo_lu is reset to 0. Afterwards, |
|
| 214 |
the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed |
|
| 215 |
to apply the new IMSI. |
|
| 190 | 216 |
|
| 191 | 217 |
// FIXME: do we need to enforce the LU now, with an arbitrary CM Service |
| 192 | 218 |
// Request, or would this only be necessary for Osmocom? (OS#4404) |
| 219 |
|
|
| 220 |
===== Warning the Subscriber If the Pseudonymous IMSI Does Not Change |
|
| 221 |
|
|
| 222 |
An attacker could potentially block the next pseudonymous IMSI SMS on purpose. |
|
| 223 |
Because the SIM applet cannot decide the next pseudonymous IMSI, it would have |
|
| 224 |
the same pseudonymous IMSI for a long time. Then it could become feasible for |
|
| 225 |
an attacker to track the subscriber by their pseudonymous IMSI. Therefore the |
|
| 226 |
SIM applet should warn the subscriber if the pseudonymous IMSI does not change. |
|
| 227 |
|
|
| 228 |
The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS |
|
| 229 |
03.19, Section 6.2) and increases imsi_pseudo_lu by 1 when the event is |
|
| 230 |
triggered. If imsi_pseudo_lu reaches imsi_pseudo_lu_max, the SIM applet |
|
| 231 |
displays a warning to the subscriber. |
|
| 232 |
|
|
| 193 | 233 |
[[process-update-location-hlr]] |
| 194 | 234 |
=== Process Update_Location_HLR |
| 195 | 235 |
|
| ... | ... | |
| 236 | 276 |
|
| 237 | 277 |
When Update Location Request arrives, the HLR does not look up the subscriber |
| 238 | 278 |
by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has |
| 239 |
two pseudonymous IMSI allocated and used the old pseudonymous IMSI in the
|
|
| 240 |
Update Location Request, this is followed by the existing logic to continue with
|
|
| 241 |
Insert Subscriber Data Request. |
|
| 279 |
two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the
|
|
| 280 |
Update Location Request, this is followed by the existing logic to continue |
|
| 281 |
with Insert Subscriber Data Request.
|
|
| 242 | 282 |
|
| 243 | 283 |
===== Update Location Request With New Pseudonymous IMSI |
| 244 | 284 |
|
| ... | ... | |
| 326 | 366 |
the HLR has both the old and the new pseudonymous IMSI allocated at this point, |
| 327 | 367 |
the subscriber is not locked out of the network. |
| 328 | 368 |
|
| 329 |
An attacker might block the next pseudonymous IMSI SMS on purpose. Then the |
|
| 330 |
subscriber would have the same pseudonymous IMSI for a long time. A suitable |
|
| 331 |
defense is warning the subscriber if the IMSI does not change |
|
| 332 |
(<<warn-no-imsi-change>>). |
|
| 333 |
|
|
| 334 | 369 |
=== Next Pseudonymous IMSI SMS arrives out of order |
| 335 | 370 |
|
| 336 | 371 |
The next pseudonymous IMSI SMS may arrive out of order. Either, because the |
| ... | ... | |
| 385 | 420 |
end encryption from the HLR to the SIM. It was considered for this |
| 386 | 421 |
specification, but found to be out of scope. |
| 387 | 422 |
|
| 388 |
[[warn-no-imsi-change]] |
|
| 389 |
=== Warning the User if the IMSI Does Not Change |
|
| 390 | 423 |
=== User-configurable Minimum Duration Between IMSI Changes |
| 391 | 424 |
|
| 392 | 425 |
<<< |
Also available in: Unified diff
spec: Warning the Subscriber If the Pseudonymous IMSI Does Not Change