264 lines
10 KiB
Plaintext
264 lines
10 KiB
Plaintext
= Specification for IMSI Pseudonymization on the Radio Interface for 2G and Above
|
|
|
|
== Introduction
|
|
|
|
=== Protecting the IMSI on the Radio Interface is Desirable
|
|
|
|
A long-standing issue in the 3GPP specifications is, that mobile phones and
|
|
other mobile equipment (ME) have to send the International Mobile Subscriber
|
|
Identity (IMSI) unencrypted over the air. Each IMSI is uniquely identifying the
|
|
person who bought the associated Subscriber Identity Module (SIM) used in the
|
|
ME. Therefore most people can be uniquely identified by recording the IMSI that
|
|
their ME is sending. Efforts are made in the 2G and above specifications to
|
|
send the IMSI less often, by using the Temporary Mobile Subscriber Identity
|
|
(TMSI) where possible.
|
|
|
|
But this is not enough. So-called IMSI catchers were invented and are used to
|
|
not only record IMSIs when they have to be sent. But also to force ME to send
|
|
their IMSI by immitating a Base Transceiver Station (BTS). IMSI catchers have
|
|
become small and affordable, even criminals actors without much budget can use
|
|
them to track anybody with a mobile phone.
|
|
|
|
=== Summary of Proposed Solution
|
|
|
|
The solution presented in this document is to periodically change the IMSI of
|
|
the ME to a new pseudonymous IMSI allocated by the Home Location Register (HLR)
|
|
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM
|
|
via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the
|
|
SIM with the new value. The only component that needs to be changed in the
|
|
network besides the SIM is the HLR/HSS, therefore it should be possible even
|
|
for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
|
enhancement.
|
|
|
|
=== Summary of Existing Location Updating Procedures in RAN and CN
|
|
|
|
The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a
|
|
subscriber, after the subscriber was added with the same data to the HLR/HSS.
|
|
In the Remote Access Network (RAN), the IMSI is sent over the air interface and
|
|
then transmitted to the Core Network (CN), where it is validated by the
|
|
HLR/HSS. The involved components vary by the generation of the network and
|
|
whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)
|
|
connection, but the principle is the same. This document uses 2G CS Location
|
|
Updating for reference, as in <<figure-imsi-regular>>.
|
|
|
|
The IMSI is transmitted in the Location Updating Request from ME. The VLR
|
|
needs an authentication challenge specific to the secret keys on the SIM to
|
|
authenticate the SIM, and looks the authentication challenges up by the IMSI.
|
|
If the VLR does not have any more authentication challenges for the IMSI (as it
|
|
happens when the VLR sees the IMSI for the first time), the VLR requests new
|
|
authentication challenges from the HLR. Then the HLR verifies that the IMSI is
|
|
known and, if it is unknown, sends back an error that will terminate the
|
|
Location Updating procedure.
|
|
|
|
After the VLR found the authentication challenge, it authenticates the SIM, and
|
|
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
|
has the required information to finish the Location Updating, and continues
|
|
with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns
|
|
a new TMSI with the Location Updating Accept, which is acknowledged by the TMSI
|
|
Reallocation Complete. In following Location Updates with the same MSC, the ME
|
|
sends the TMSI instead of the IMSI in the Location Updating Request.
|
|
|
|
[[figure-imsi-regular]]
|
|
.Location Updating in 2G CS with IMSI
|
|
["mscgen"]
|
|
----
|
|
msc {
|
|
hscale="1.75";
|
|
ME [label="ME"], BTS [label="BTS"], BSC [label="BSC"], MSC [label="MSC/VLR"],
|
|
HLR [label="HLR"];
|
|
|
|
// BTS <=> BSC: RSL
|
|
// BSC <=> MSC: BSSAP, RNSAP
|
|
// MSC <=> HLR: MAP (process Update_Location_HLR, 3GPP TS 29.002)
|
|
|
|
ME => BTS [label="Location Updating Request"];
|
|
BTS => BSC [label="Location Updating Request"];
|
|
BSC => MSC [label="Location Updating Request"];
|
|
|
|
--- [label="VLR requests new authentication challenges for this IMSI if necessary"];
|
|
MSC => HLR [label="Send Auth Info Request"];
|
|
MSC <= HLR [label="Send Auth Info Result"];
|
|
---;
|
|
|
|
BSC <= MSC [label="Authentication Request"];
|
|
BTS <= BSC [label="Authentication Request"];
|
|
ME <= BTS [label="Authentication Request"];
|
|
ME => BTS [label="Authentication Response"];
|
|
BTS => BSC [label="Authentication Response"];
|
|
BSC => MSC [label="Authentication Response"];
|
|
BSC <= MSC [label="Classmark Enquiry"];
|
|
BTS <= BSC [label="Classmark Enquiry"];
|
|
ME <= BTS [label="Classmark Enquiry"];
|
|
ME => BTS [label="Classmark Change"];
|
|
BTS => BSC [label="Classmark Change"];
|
|
BSC => MSC [label="Classmark Update"];
|
|
BSC <= MSC [label="Physical Channel Reconfiguration"];
|
|
BTS <= BSC [label="Ciphering Mode Command"];
|
|
ME <= BTS [label="Ciphering Mode Command"];
|
|
ME => BTS [label="Ciphering Mode Complete"];
|
|
BTS => BSC [label="Ciphering Mode Complete"];
|
|
BSC => MSC [label="Ciphering Mode Complete"];
|
|
|
|
--- [label="Process Update_Location_HLR (3GPP TS 29.002)"];
|
|
MSC => HLR [label="Update Location Request"];
|
|
MSC <= HLR [label="Insert Subscriber Data Request"];
|
|
MSC => HLR [label="Insert Subscriber Data Result"];
|
|
MSC <= HLR [label="Update Location Result"];
|
|
---;
|
|
|
|
BSC <= MSC [label="Location Updating Accept"];
|
|
BTS <= BSC [label="Location Updating Accept"];
|
|
ME <= BTS [label="Location Updating Accept"];
|
|
ME => BTS [label="TMSI Reallocation Complete"];
|
|
BTS => BSC [label="TMSI Reallocation Complete"];
|
|
BSC => MSC [label="TMSI Reallocation Complete"];
|
|
}
|
|
----
|
|
|
|
<<<
|
|
== Required Changes
|
|
|
|
=== Pseudonymous IMSI Storage in the HLR
|
|
|
|
The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related
|
|
counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one
|
|
pseudonymous IMSI allocated. A subscriber has two valid pseudonymous IMSIs
|
|
only during the transition phase from the old pseudonymous IMSI to the new one.
|
|
The amount of available IMSIs must be higher than the amount of subscribers
|
|
registered with the HLR. If the amount of available IMSIs is too short, the HLR
|
|
can delay assigning new pseudonymous IMSIs until new IMSIs are available again.
|
|
|
|
.Examples for additional subscriber data in HLR
|
|
|===
|
|
| Subscriber ID | imsi_pseudo | imsi_pseudo_i
|
|
// example IMSIs taken from Wikipedia
|
|
| 123
|
|
| 310150123456789
|
|
| 1
|
|
|
|
| 234
|
|
| 502130123456789
|
|
| 1
|
|
|
|
| 234
|
|
| 460001357924680
|
|
| 2
|
|
|===
|
|
|
|
==== imsi_pseudo
|
|
|
|
The value for imsi_pseudo is a random choice from the pool of available IMSIs
|
|
that the HLR controls. The pseudonymous IMSI must not be used by any subscriber
|
|
as pseudonymous IMSI yet, but may be the real IMSI of a subscriber.
|
|
|
|
[[hlr-imsi-pseudo-i]]
|
|
==== imsi_pseudo_i
|
|
|
|
The counter imsi_pseudo_i indicates how often a subscriber's pseudonymous IMSI
|
|
was changed. The value is 1 for the first allocated pseudonymous IMSI of a
|
|
subscriber. When allocating a new pseudonymous IMSI for the same subscriber,
|
|
the new imsi_pseudo_i value is increased by 1. The counter is used by the SIM
|
|
applet to detect and ignore outdated requests related to changing the
|
|
pseudonymous IMSI.
|
|
|
|
=== SIM Provisioning
|
|
|
|
The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous
|
|
IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI.
|
|
|
|
==== SIM applet
|
|
|
|
The SIM is provisioned with a SIM applet, which is able to change the IMSI once
|
|
the next pseudonymous IMSI arrives from the HLR. A reference implementation is
|
|
provided in <<reference-src>>.
|
|
|
|
The SIM applet registers to a suitable SMS trigger (3GPP TS 03.19, Section
|
|
6.2). When an SMS from the HLR in the format of <<sms-format>> arrives, the
|
|
applet must verify that the SMS is not outdated by comparing imsi_pseudo_i from
|
|
the SMS with the last imsi_pseudo_i that was used when changing the IMSI
|
|
(initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher,
|
|
otherwise the SMS should not be processed further.
|
|
|
|
The SIM applet registers a timer with min_sleep_time from the SMS. When the
|
|
timer triggers, the IMSI of the SIM is overwritten with the new pseudonymous
|
|
IMSI, the TMSI and GSM Ciphering key Kc (3GPP TS 31.102, Section 4.4.3.1) are
|
|
invalidated. The current imsi_pseudo_i value is stored to compare it with the
|
|
next SMS. Afterwards, the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section
|
|
6.4.7.1 is executed to apply the new IMSI.
|
|
|
|
// FIXME: do we need to enforce the LU now, with an arbitrary CM Service
|
|
// Request, or would this only be necessary for Osmocom? (OS#4404)
|
|
|
|
=== Process Update_Location_HLR
|
|
|
|
All IMSI Pseudonymization related changes to Process Update_Location_HLR
|
|
(3GPP TS 29.002) are optional.
|
|
|
|
* HLR looks up subscriber by pseudonymous imsi in Update Location Request
|
|
* if two pseudo imsi found, and connected with new one: dealloc old entry
|
|
* if two pseudo imsi found and connected with old one: do not dealloc!
|
|
|
|
* after update location result: set new timer for sending next IMSI to random delay
|
|
|
|
==== Send Next Pseudonymous IMSI
|
|
|
|
* if subscriber has two pseudo IMSI, send the new one
|
|
* if subscriber has only one pseudo IMSI:
|
|
* abort if not enough IMSIs available
|
|
* generate new pseudo IMSI as described earlier
|
|
* set imsi_pseudo_i like last one + 1
|
|
* send SMS to subscriber's SIM
|
|
|
|
[[sms-format]]
|
|
==== SMS Format
|
|
|
|
* min_sleep_time
|
|
* imsi_pseudo
|
|
* imsi_pseudo_i
|
|
|
|
[[figure-]]
|
|
.Process Update_Location_HLR with IMSI pseudonymization changes
|
|
["mscgen"]
|
|
----
|
|
msc {
|
|
hscale="1.75";
|
|
MSC [label="MSC/VLR"], SMSC [label="SMS-SC"], HLR [label="HLR"];
|
|
|
|
MSC => HLR [label="Update Location Request"];
|
|
HLR box HLR [label="\nDeallocate old Pseudonymous IMSI,\n if new Pseudonymous IMSI was used\n"];
|
|
MSC <= HLR [label="Insert Subscriber Data Request"];
|
|
MSC => HLR [label="Insert Subscriber Data Result"];
|
|
HLR box HLR [label="Start Next_Pseudo_IMSI_Timer"];
|
|
MSC <= HLR [label="Update Location Result"];
|
|
|
|
MSC box MSC [label="Finish Location Updating with ME"],
|
|
HLR box HLR [label="Wait for Next_Pseudo_IMSI_Timer expiry"];
|
|
|||;
|
|
...;
|
|
|||;
|
|
HLR box HLR [label="Next_Pseudo_IMSI_Timer expired"];
|
|
HLR box HLR [label="\nAllocate new Pseudonymous IMSI\nif subscriber only has one allocated\n"];
|
|
SMSC <= HLR [label="Next Pseudonymous IMSI SMS"];
|
|
SMSC box SMSC [label="Deliver SMS to ME"];
|
|
}
|
|
----
|
|
|
|
== Error Scenarios
|
|
=== Next Pseudonymous IMSI SMS is Lost
|
|
=== SMS Arrives Late
|
|
|
|
// === SMS Arrives Before Timer Expires
|
|
// FIXME: OS#4486
|
|
|
|
[[reference-src]]
|
|
== Reference Implementation with Source Code
|
|
|
|
== Recommendations for Real-World Implementations
|
|
=== ATT = 0
|
|
=== End to End Encryption of SMS
|
|
=== Warning the User if the IMSI Does Not Change
|
|
=== User-configurable Minimum Duration Between IMSI Changes
|
|
|
|
<<<
|
|
include::./common/chapters/gfdl.adoc[]
|