Revision cbe90581
Added by osmith about 4 years ago
| docs/imsi-pseudo-spec.adoc | ||
|---|---|---|
| 359 | 359 |
well. |
| 360 | 360 |
|
| 361 | 361 |
== Recommendations for Real-World Implementations |
| 362 |
|
|
| 362 | 363 |
=== BCCH SI3: ATT = 0 |
| 364 |
|
|
| 363 | 365 |
When changing from one pseudonymous IMSI to the next, it is important that the |
| 364 | 366 |
ME does not detach from the network. Otherwise it would be trivial for an |
| 365 | 367 |
attacker to correlate the detach with the attach of the same ME with the next |
| ... | ... | |
| 372 | 374 |
// FIXME: verify how it set with operators in germany (OS#4404) |
| 373 | 375 |
|
| 374 | 376 |
=== End to End Encryption of SMS |
| 377 |
|
|
| 378 |
When deploying the IMSI pseudonymization, the operator should make sure that |
|
| 379 |
the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified |
|
| 380 |
by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the |
|
| 381 |
pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the |
|
| 382 |
network. |
|
| 383 |
|
|
| 384 |
The safest way to protect the next pseudonymous IMSI SMS is a layer of end to |
|
| 385 |
end encryption from the HLR to the SIM. It was considered for this |
|
| 386 |
specification, but found to be out of scope. |
|
| 387 |
|
|
| 375 | 388 |
[[warn-no-imsi-change]] |
| 376 | 389 |
=== Warning the User if the IMSI Does Not Change |
| 377 | 390 |
=== User-configurable Minimum Duration Between IMSI Changes |
Also available in: Unified diff
spec: end to end enc