Revision 7afd7010
Added by osmith about 4 years ago
docs/imsi-pseudo-spec.adoc | ||
---|---|---|
8 | 8 |
person who bought the associated Subscriber Identity Module (SIM) used in the |
9 | 9 |
ME. Therefore most people can be uniquely identified by recording the IMSI that |
10 | 10 |
their ME is sending. Efforts are made in the 2G and above specifications to |
11 |
send the IMSI less often, and where possible use the Temporary Mobile
|
|
12 |
Subscriber Identity (TMSI) instead.
|
|
11 |
send the IMSI less often, by using the Temporary Mobile Subscriber Identity
|
|
12 |
(TMSI) where possible.
|
|
13 | 13 |
|
14 | 14 |
But this is not enough. So-called IMSI catchers were invented and are used to |
15 | 15 |
not only record IMSIs when they have to be sent. But also to force ME to send |
... | ... | |
21 | 21 |
the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR) |
22 | 22 |
or Home Subscriber Service (HSS). The only component that needs to be changed |
23 | 23 |
in the network besides the SIM is the HLR/HSS, therefore it should be possible |
24 |
for a Mobile Virtual Network Operator (MVNO) to deploy this privacy |
|
24 |
even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
|
25 | 25 |
enhancement. |
26 | 26 |
|
27 |
== Location Update
|
|
27 |
== Location Updating
|
|
28 | 28 |
|
29 | 29 |
=== Regular |
30 | 30 |
|
31 |
=== With Pseudonymous IMSI |
|
31 |
The SIM is provisioned with the IMSI (3GPP TS 23.008 section 2.1.9) and |
|
32 |
cryptographic keys, that it uses to authenticate with the network. In the |
|
33 |
Remote Access Network (RAN), the IMSI is sent over the air interface and then |
|
34 |
transmitted to the Core Network (CN), where it is validated by the HLR/HSS. |
|
35 |
The involved components vary by the generation of the network and whether the |
|
36 |
SIM is attempting a Circuit Switched (CS) or Packet Switched (PS) connection. |
|
37 |
But the principle is the same and looks like <<figure-imsi-regular>> for 2G CS |
|
38 |
Location Updating with IMSI. |
|
39 |
|
|
40 |
The IMSI is transmitted in the Location Updating Request from ME. The VLR |
|
41 |
needs an authentication challenge specific to the secret keys on the SIM to |
|
42 |
authenticate the SIM, and looks the authentication challenges up by the IMSI. |
|
43 |
If the VLR does not have any more authentication challenges for the IMSI (as it |
|
44 |
happens when the VLR sees the IMSI for the first time), the VLR requests new |
|
45 |
authentication challenges from the HLR. Then the HLR verifies that the IMSI is |
|
46 |
known and, if it is unknown, sends back an error that will terminate the |
|
47 |
Location Updating procedure. |
|
48 |
|
|
49 |
After the VLR found the authentication challenge, it authenticates the SIM, and |
|
50 |
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR |
|
51 |
has the required information to finish the Location Updating, and continues |
|
52 |
with an Update Location Request procedure with the HLR. Afterwards, the VLR |
|
53 |
assigns a new TMSI with the Location Updating Accept, which is acknowledged by |
|
54 |
the TMSI Reallocation Complete. In following Location Updates with the same |
|
55 |
MSC, the ME sends the TMSI instead of the IMSI in the Location Updating |
|
56 |
Request. |
|
57 |
|
|
58 |
[[figure-imsi-regular]] |
|
59 |
.Location Updating in 2G CS with IMSI |
|
60 |
["mscgen"] |
|
61 |
---- |
|
62 |
msc { |
|
63 |
hscale="1.75"; |
|
64 |
ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"], |
|
65 |
HLR [label="HLR"]; |
|
66 |
|
|
67 |
// BTS <=> BSC: RSL |
|
68 |
// BSC <=> MSC: BSSAP, RNSAP |
|
69 |
// MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002) |
|
70 |
|
|
71 |
ME => BTS [label="Location Updating Request"]; |
|
72 |
BTS => BSC [label="Location Updating Request"]; |
|
73 |
BSC => MSC [label="Location Updating Request"]; |
|
74 |
|
|
75 |
--- [label="VLR requests new authentication challenges for this IMSI if necessary"]; |
|
76 |
MSC => HLR [label="Send Auth Info Request"]; |
|
77 |
MSC <= HLR [label="Send Auth Info Result"]; |
|
78 |
---; |
|
79 |
|
|
80 |
BSC <= MSC [label="Authentication Request"]; |
|
81 |
BTS <= BSC [label="Authentication Request"]; |
|
82 |
ME <= BTS [label="Authentication Request"]; |
|
83 |
ME => BTS [label="Authentication Response"]; |
|
84 |
BTS => BSC [label="Authentication Response"]; |
|
85 |
BSC => MSC [label="Authentication Response"]; |
|
86 |
BSC <= MSC [label="Classmark Enquiry"]; |
|
87 |
BTS <= BSC [label="Classmark Enquiry"]; |
|
88 |
ME <= BTS [label="Classmark Enquiry"]; |
|
89 |
ME => BTS [label="Classmark Change"]; |
|
90 |
BTS => BSC [label="Classmark Change"]; |
|
91 |
BSC => MSC [label="Classmark Update"]; |
|
92 |
BSC <= MSC [label="Physical Channel Reconfiguration"]; |
|
93 |
BTS <= BSC [label="Ciphering Mode Command"]; |
|
94 |
ME <= BTS [label="Ciphering Mode Command"]; |
|
95 |
ME => BTS [label="Ciphering Mode Complete"]; |
|
96 |
BTS => BSC [label="Ciphering Mode Complete"]; |
|
97 |
BSC => MSC [label="Ciphering Mode Complete"]; |
|
98 |
|
|
99 |
MSC => HLR [label="Update Location Request"]; |
|
100 |
MSC <= HLR [label="Insert Subscriber Data Request"]; |
|
101 |
MSC => HLR [label="Insert Subscriber Data Result"]; |
|
102 |
MSC <= HLR [label="Update Location Result"]; |
|
103 |
|
|
104 |
BSC <= MSC [label="Location Updating Accept"]; |
|
105 |
BTS <= BSC [label="Location Updating Accept"]; |
|
106 |
ME <= BTS [label="Location Updating Accept"]; |
|
107 |
ME => BTS [label="TMSI Reallocation Complete"]; |
|
108 |
BTS => BSC [label="TMSI Reallocation Complete"]; |
|
109 |
} |
|
110 |
---- |
|
111 |
|
|
112 |
=== With IMSI Pseudonymization |
|
113 |
|
|
114 |
==== SIM Provisioning |
|
115 |
|
|
116 |
==== Successful Location Update With Pseudonymous IMSI |
|
117 |
|
|
118 |
==== Next Pseudonymous IMSI Arrives Via SMS |
|
119 |
|
|
120 |
==== Error Handling |
|
121 |
|
|
122 |
===== SMS is Lost |
|
123 |
|
|
124 |
===== SMS Arrives Late |
|
32 | 125 |
|
33 | 126 |
== Implementation Notes |
34 | 127 |
|
35 | 128 |
=== Source Code for Reference Implementation |
36 | 129 |
|
130 |
=== ATT = 0 required |
|
131 |
|
|
37 | 132 |
=== Warning the User if the IMSI Does Not Change |
38 | 133 |
|
39 | 134 |
=== End to End Encryption of SMS |
Also available in: Unified diff
spec: describe LU without pseudo IMSI