1 |
5c95bc9c
|
Oliver Smith
|
= Specification for IMSI Pseudonymization on the Radio Interface for 2G and Above
|
2 |
|
|
|
3 |
|
|
== Introduction
|
4 |
|
|
|
5 |
|
|
A long-standing issue in the 3GPP specifications is, that mobile phones and
|
6 |
|
|
other mobile equipment (ME) have to send the International Mobile Subscriber
|
7 |
|
|
Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the
|
8 |
|
|
person who bought the associated Subscriber Identity Module (SIM) used in the
|
9 |
|
|
ME. Therefore most people can be uniquely identified by recording the IMSI that
|
10 |
|
|
their ME is sending. Efforts are made in the 2G and above specifications to
|
11 |
7afd7010
|
Oliver Smith
|
send the IMSI less often, by using the Temporary Mobile Subscriber Identity
|
12 |
|
|
(TMSI) where possible.
|
13 |
5c95bc9c
|
Oliver Smith
|
|
14 |
|
|
But this is not enough. So-called IMSI catchers were invented and are used to
|
15 |
|
|
not only record IMSIs when they have to be sent. But also to force ME to send
|
16 |
|
|
their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have
|
17 |
|
|
become small and affordable, even criminals actors without much budget can use
|
18 |
|
|
them to track anybody with a mobile phone.
|
19 |
|
|
|
20 |
|
|
The solution presented in this document is to periodically change the IMSI of
|
21 |
|
|
the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR)
|
22 |
|
|
or Home Subscriber Service (HSS). The only component that needs to be changed
|
23 |
|
|
in the network besides the SIM is the HLR/HSS, therefore it should be possible
|
24 |
7afd7010
|
Oliver Smith
|
even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
25 |
5c95bc9c
|
Oliver Smith
|
enhancement.
|
26 |
|
|
|
27 |
7afd7010
|
Oliver Smith
|
== Location Updating
|
28 |
5c95bc9c
|
Oliver Smith
|
|
29 |
|
|
=== Regular
|
30 |
|
|
|
31 |
7afd7010
|
Oliver Smith
|
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
|
125 |
5c95bc9c
|
Oliver Smith
|
|
126 |
|
|
== Implementation Notes
|
127 |
|
|
|
128 |
|
|
=== Source Code for Reference Implementation
|
129 |
|
|
|
130 |
7afd7010
|
Oliver Smith
|
=== ATT = 0 required
|
131 |
|
|
|
132 |
5c95bc9c
|
Oliver Smith
|
=== Warning the User if the IMSI Does Not Change
|
133 |
|
|
|
134 |
|
|
=== End to End Encryption of SMS
|
135 |
|
|
|
136 |
|
|
=== User-configurable Minimum Duration Between IMSI Changes
|