1
|
= 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
|
send the IMSI less often, by using the Temporary Mobile Subscriber Identity
|
12
|
(TMSI) where possible.
|
13
|
|
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
|
even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
25
|
enhancement.
|
26
|
|
27
|
== Summary of Existing Location Updating Procedures in RAN and CN
|
28
|
|
29
|
The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a
|
30
|
subscriber, after the subscriber was added with the same data to the HLR/HSS.
|
31
|
In the Remote Access Network (RAN), the IMSI is sent over the air interface and
|
32
|
then transmitted to the Core Network (CN), where it is validated by the
|
33
|
HLR/HSS. The involved components vary by the generation of the network and
|
34
|
whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)
|
35
|
connection, but the principle is the same. This document uses 2G CS Location
|
36
|
Updating for reference, as in <<figure-imsi-regular>>.
|
37
|
|
38
|
The IMSI is transmitted in the Location Updating Request from ME. The VLR
|
39
|
needs an authentication challenge specific to the secret keys on the SIM to
|
40
|
authenticate the SIM, and looks the authentication challenges up by the IMSI.
|
41
|
If the VLR does not have any more authentication challenges for the IMSI (as it
|
42
|
happens when the VLR sees the IMSI for the first time), the VLR requests new
|
43
|
authentication challenges from the HLR. Then the HLR verifies that the IMSI is
|
44
|
known and, if it is unknown, sends back an error that will terminate the
|
45
|
Location Updating procedure.
|
46
|
|
47
|
After the VLR found the authentication challenge, it authenticates the SIM, and
|
48
|
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
49
|
has the required information to finish the Location Updating, and continues
|
50
|
with an Update Location Request procedure with the HLR. Afterwards, the VLR
|
51
|
assigns a new TMSI with the Location Updating Accept, which is acknowledged by
|
52
|
the TMSI Reallocation Complete. In following Location Updates with the same
|
53
|
MSC, the ME sends the TMSI instead of the IMSI in the Location Updating
|
54
|
Request.
|
55
|
|
56
|
[[figure-imsi-regular]]
|
57
|
.Location Updating in 2G CS with IMSI
|
58
|
["mscgen"]
|
59
|
----
|
60
|
msc {
|
61
|
hscale="1.75";
|
62
|
ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"],
|
63
|
HLR [label="HLR"];
|
64
|
|
65
|
// BTS <=> BSC: RSL
|
66
|
// BSC <=> MSC: BSSAP, RNSAP
|
67
|
// MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002)
|
68
|
|
69
|
ME => BTS [label="Location Updating Request"];
|
70
|
BTS => BSC [label="Location Updating Request"];
|
71
|
BSC => MSC [label="Location Updating Request"];
|
72
|
|
73
|
--- [label="VLR requests new authentication challenges for this IMSI if necessary"];
|
74
|
MSC => HLR [label="Send Auth Info Request"];
|
75
|
MSC <= HLR [label="Send Auth Info Result"];
|
76
|
---;
|
77
|
|
78
|
BSC <= MSC [label="Authentication Request"];
|
79
|
BTS <= BSC [label="Authentication Request"];
|
80
|
ME <= BTS [label="Authentication Request"];
|
81
|
ME => BTS [label="Authentication Response"];
|
82
|
BTS => BSC [label="Authentication Response"];
|
83
|
BSC => MSC [label="Authentication Response"];
|
84
|
BSC <= MSC [label="Classmark Enquiry"];
|
85
|
BTS <= BSC [label="Classmark Enquiry"];
|
86
|
ME <= BTS [label="Classmark Enquiry"];
|
87
|
ME => BTS [label="Classmark Change"];
|
88
|
BTS => BSC [label="Classmark Change"];
|
89
|
BSC => MSC [label="Classmark Update"];
|
90
|
BSC <= MSC [label="Physical Channel Reconfiguration"];
|
91
|
BTS <= BSC [label="Ciphering Mode Command"];
|
92
|
ME <= BTS [label="Ciphering Mode Command"];
|
93
|
ME => BTS [label="Ciphering Mode Complete"];
|
94
|
BTS => BSC [label="Ciphering Mode Complete"];
|
95
|
BSC => MSC [label="Ciphering Mode Complete"];
|
96
|
|
97
|
MSC => HLR [label="Update Location Request"];
|
98
|
MSC <= HLR [label="Insert Subscriber Data Request"];
|
99
|
MSC => HLR [label="Insert Subscriber Data Result"];
|
100
|
MSC <= HLR [label="Update Location Result"];
|
101
|
|
102
|
BSC <= MSC [label="Location Updating Accept"];
|
103
|
BTS <= BSC [label="Location Updating Accept"];
|
104
|
ME <= BTS [label="Location Updating Accept"];
|
105
|
ME => BTS [label="TMSI Reallocation Complete"];
|
106
|
BTS => BSC [label="TMSI Reallocation Complete"];
|
107
|
BSC => MSC [label="TMSI Reallocation Complete"];
|
108
|
}
|
109
|
----
|
110
|
|
111
|
== Required Changes
|
112
|
|
113
|
=== SIM Provisioning
|
114
|
|
115
|
|
116
|
|
117
|
|
118
|
=== Successful Location Update With Pseudonymous IMSI
|
119
|
=== Next Pseudonymous IMSI Arrives Via SMS
|
120
|
|
121
|
== Error Scenarios
|
122
|
=== Next Pseudonymous IMSI SMS is Lost
|
123
|
=== SMS Arrives Late
|
124
|
|
125
|
== Reference Implementation with Source Code
|
126
|
|
127
|
== Recommendations for Real-World Implementations
|
128
|
=== ATT = 0
|
129
|
=== End to End Encryption of SMS
|
130
|
=== Warning the User if the IMSI Does Not Change
|
131
|
=== User-configurable Minimum Duration Between IMSI Changes
|
132
|
|
133
|
<<<
|
134
|
include::./common/chapters/gfdl.adoc[]
|