1
|
= Specification for IMSI Pseudonymization on the Radio Interface for 2G and Above
|
2
|
|
3
|
== Introduction
|
4
|
|
5
|
=== Protecting the IMSI on the Radio Interface is Desirable
|
6
|
|
7
|
A long-standing issue in the 3GPP specifications is, that mobile phones and
|
8
|
other mobile equipment (ME) have to send the International Mobile Subscriber
|
9
|
Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the
|
10
|
person who bought the associated Subscriber Identity Module (SIM) used in the
|
11
|
ME. Therefore most people can be uniquely identified by recording the IMSI that
|
12
|
their ME is sending. Efforts are made in the 2G and above specifications to
|
13
|
send the IMSI less often, by using the Temporary Mobile Subscriber Identity
|
14
|
(TMSI) where possible.
|
15
|
|
16
|
But this is not enough. So-called IMSI catchers were invented and are used to
|
17
|
not only record IMSIs when they have to be sent. But also to force ME to send
|
18
|
their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have
|
19
|
become small and affordable, even criminals actors without much budget can use
|
20
|
them to track anybody with a mobile phone.
|
21
|
|
22
|
=== Summary of Proposed Solution
|
23
|
|
24
|
The solution presented in this document is to periodically change the IMSI of
|
25
|
the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR)
|
26
|
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM
|
27
|
via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the
|
28
|
SIM with the new value. The only component that needs to be changed in the
|
29
|
network besides the SIM is the HLR/HSS, therefore it should be possible even
|
30
|
for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
31
|
enhancement.
|
32
|
|
33
|
=== Summary of Existing Location Updating Procedures in RAN and CN
|
34
|
|
35
|
The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a
|
36
|
subscriber, after the subscriber was added with the same data to the HLR/HSS.
|
37
|
In the Remote Access Network (RAN), the IMSI is sent over the air interface and
|
38
|
then transmitted to the Core Network (CN), where it is validated by the
|
39
|
HLR/HSS. The involved components vary by the generation of the network and
|
40
|
whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)
|
41
|
connection, but the principle is the same. This document uses 2G CS Location
|
42
|
Updating for reference, as in <<figure-imsi-regular>>.
|
43
|
|
44
|
The IMSI is transmitted in the Location Updating Request from ME. The VLR
|
45
|
needs an authentication challenge specific to the secret keys on the SIM to
|
46
|
authenticate the SIM, and looks the authentication challenges up by the IMSI.
|
47
|
If the VLR does not have any more authentication challenges for the IMSI (as it
|
48
|
happens when the VLR sees the IMSI for the first time), the VLR requests new
|
49
|
authentication challenges from the HLR. Then the HLR verifies that the IMSI is
|
50
|
known and, if it is unknown, sends back an error that will terminate the
|
51
|
Location Updating procedure.
|
52
|
|
53
|
After the VLR found the authentication challenge, it authenticates the SIM, and
|
54
|
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
55
|
has the required information to finish the Location Updating, and continues
|
56
|
with an Update Location Request procedure with the HLR. Afterwards, the VLR
|
57
|
assigns a new TMSI with the Location Updating Accept, which is acknowledged by
|
58
|
the TMSI Reallocation Complete. In following Location Updates with the same
|
59
|
MSC, the ME sends the TMSI instead of the IMSI in the Location Updating
|
60
|
Request.
|
61
|
|
62
|
[[figure-imsi-regular]]
|
63
|
.Location Updating in 2G CS with IMSI
|
64
|
["mscgen"]
|
65
|
----
|
66
|
msc {
|
67
|
hscale="1.75";
|
68
|
ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"],
|
69
|
HLR [label="HLR"];
|
70
|
|
71
|
// BTS <=> BSC: RSL
|
72
|
// BSC <=> MSC: BSSAP, RNSAP
|
73
|
// MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002)
|
74
|
|
75
|
ME => BTS [label="Location Updating Request"];
|
76
|
BTS => BSC [label="Location Updating Request"];
|
77
|
BSC => MSC [label="Location Updating Request"];
|
78
|
|
79
|
--- [label="VLR requests new authentication challenges for this IMSI if necessary"];
|
80
|
MSC => HLR [label="Send Auth Info Request"];
|
81
|
MSC <= HLR [label="Send Auth Info Result"];
|
82
|
---;
|
83
|
|
84
|
BSC <= MSC [label="Authentication Request"];
|
85
|
BTS <= BSC [label="Authentication Request"];
|
86
|
ME <= BTS [label="Authentication Request"];
|
87
|
ME => BTS [label="Authentication Response"];
|
88
|
BTS => BSC [label="Authentication Response"];
|
89
|
BSC => MSC [label="Authentication Response"];
|
90
|
BSC <= MSC [label="Classmark Enquiry"];
|
91
|
BTS <= BSC [label="Classmark Enquiry"];
|
92
|
ME <= BTS [label="Classmark Enquiry"];
|
93
|
ME => BTS [label="Classmark Change"];
|
94
|
BTS => BSC [label="Classmark Change"];
|
95
|
BSC => MSC [label="Classmark Update"];
|
96
|
BSC <= MSC [label="Physical Channel Reconfiguration"];
|
97
|
BTS <= BSC [label="Ciphering Mode Command"];
|
98
|
ME <= BTS [label="Ciphering Mode Command"];
|
99
|
ME => BTS [label="Ciphering Mode Complete"];
|
100
|
BTS => BSC [label="Ciphering Mode Complete"];
|
101
|
BSC => MSC [label="Ciphering Mode Complete"];
|
102
|
|
103
|
MSC => HLR [label="Update Location Request"];
|
104
|
MSC <= HLR [label="Insert Subscriber Data Request"];
|
105
|
MSC => HLR [label="Insert Subscriber Data Result"];
|
106
|
MSC <= HLR [label="Update Location Result"];
|
107
|
|
108
|
BSC <= MSC [label="Location Updating Accept"];
|
109
|
BTS <= BSC [label="Location Updating Accept"];
|
110
|
ME <= BTS [label="Location Updating Accept"];
|
111
|
ME => BTS [label="TMSI Reallocation Complete"];
|
112
|
BTS => BSC [label="TMSI Reallocation Complete"];
|
113
|
BSC => MSC [label="TMSI Reallocation Complete"];
|
114
|
}
|
115
|
----
|
116
|
|
117
|
<<<
|
118
|
== Required Changes
|
119
|
|
120
|
=== Pseudonymous IMSI Storage in the HLR
|
121
|
|
122
|
The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related
|
123
|
counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one
|
124
|
pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs
|
125
|
only during the transition phase from the old pseudonymous IMSI to the new one.
|
126
|
The amount of available IMSIs must be higher than the amount of subscribers
|
127
|
registered with the HLR. If the amount of available IMSIs is too short, the HLR
|
128
|
can delay assigning new pseudonymous IMSIs until new IMSIs are available again.
|
129
|
|
130
|
.Examples for additional subscriber data in HLR
|
131
|
|===
|
132
|
| Subscriber ID | imsi_pseudo | imsi_pseudo_i
|
133
|
// example IMSIs taken from Wikipedia
|
134
|
| 123
|
135
|
| 310150123456789
|
136
|
| 1
|
137
|
|
138
|
| 234
|
139
|
| 502130123456789
|
140
|
| 1
|
141
|
|
142
|
| 234
|
143
|
| 460001357924680
|
144
|
| 2
|
145
|
|===
|
146
|
|
147
|
==== imsi_pseudo
|
148
|
|
149
|
The value for imsi_pseudo is a random choice from the pool of available IMSIs
|
150
|
that the HLR controls. The pseudonymous IMSI must not be used by any subscriber
|
151
|
as pseudonymous IMSI yet, but may be the real IMSI of a subscriber.
|
152
|
|
153
|
==== imsi_pseudo_i
|
154
|
|
155
|
The counter imsi_pseudo_i indicates how often a subscriber's pseudonymous IMSI
|
156
|
was changed. The value is 1 for the first allocated pseudonymous IMSI of a
|
157
|
subscriber. When allocating a new pseudonymous IMSI for the same subscriber,
|
158
|
the new imsi_pseudo_i value is increased by 1. The counter is used by the SIM
|
159
|
applet to detect and ignore outdated requests related to changing the
|
160
|
pseudonymous IMSI.
|
161
|
|
162
|
=== SIM Provisioning
|
163
|
|
164
|
=== Successful Location Update With Pseudonymous IMSI
|
165
|
|
166
|
// HLR may choose not to give out next IMSI if it is short on available IMSIS
|
167
|
|
168
|
=== Next Pseudonymous IMSI Arrives Via SMS
|
169
|
|
170
|
== Error Scenarios
|
171
|
=== Next Pseudonymous IMSI SMS is Lost
|
172
|
=== SMS Arrives Late
|
173
|
|
174
|
== Reference Implementation with Source Code
|
175
|
|
176
|
== Recommendations for Real-World Implementations
|
177
|
=== ATT = 0
|
178
|
=== End to End Encryption of SMS
|
179
|
=== Warning the User if the IMSI Does Not Change
|
180
|
=== User-configurable Minimum Duration Between IMSI Changes
|
181
|
|
182
|
<<<
|
183
|
include::./common/chapters/gfdl.adoc[]
|