spec: Expanding text in some places; language improvements
This commit is contained in:
parent
b80a9f87e4
commit
9db94bbf89
|
@ -4,58 +4,96 @@
|
||||||
|
|
||||||
=== Protecting the IMSI on the Radio Interface is Desirable
|
=== Protecting the IMSI on the Radio Interface is Desirable
|
||||||
|
|
||||||
A long-standing issue in the 3GPP specifications is, that mobile phones and
|
A long-standing issue in the 3GPP specifications for cellular mobile
|
||||||
|
communications starting from 2G (GSM) is, that mobile phones and
|
||||||
other mobile equipment (ME) have to send the International Mobile Subscriber
|
other mobile equipment (ME) have to send the International Mobile Subscriber
|
||||||
Identity (IMSI) unencrypted over the air. Each IMSI is a unique identifier for
|
Identity (IMSI) unencrypted over the air. Each IMSI is a unique identifier for
|
||||||
the subscriber. Therefore most people can be uniquely identified by recording
|
the subscriber. Therefore, most people can be uniquely identified by recording
|
||||||
the IMSI that their ME is sending. The 3GPP specifications provide means for
|
the IMSI that their ME is sending.
|
||||||
implementations 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
|
The 3GPP specifications provide means for implementations to send the
|
||||||
not only record IMSIs when they have to be sent. But also to force ME to send
|
IMSI less often by using the Temporary Mobile Subscriber Identity (TMSI)
|
||||||
their IMSI by imitating a Base Transceiver Station (BTS). IMSI catchers have
|
where possible. However, the decision on when to use IMSI or TMSI is
|
||||||
become small and affordable, even criminals actors without much budget can use
|
entirely on the networks side, without any control by the ME or even the
|
||||||
them to track anybody with a mobile phone.
|
subscriber.
|
||||||
|
|
||||||
|
This leads to a variety of attacks on subscriber location privacy, including
|
||||||
|
the use of passive air-interface sniffing as well as false base station
|
||||||
|
attacks, where an attacker impersonates a base station which
|
||||||
|
subsequently inquires every ME about its IMSI.
|
||||||
|
|
||||||
|
Some related devices have been termed _IMSI catchers_ or _Stingray_ in
|
||||||
|
both scientific literature as well as mainstream media. IMSI catchers have
|
||||||
|
become small and affordable during the last decade; criminals actors
|
||||||
|
and in some cases even tabloid journalists without much budget have
|
||||||
|
reportedly used them to track anybody with a mobile phone.
|
||||||
|
|
||||||
5G addresses this problem with the Subscriber Concealed Identifier (SUCI),
|
5G addresses this problem with the Subscriber Concealed Identifier (SUCI),
|
||||||
which uses public-key cryptography to ensure that the permanent subscriber
|
which uses public-key cryptography to ensure that the permanent subscriber
|
||||||
identity can only be read by the home network (3GPP TS 33.501, Section 6.12.2).
|
identity (IMSI) is not transmitted over the air interface anymore.
|
||||||
A comparable, but different approach to conceal the IMSI for 2G, 3G and 4G is
|
Rather, a concealed version of it is transmitted (3GPP TS 33.501,
|
||||||
provided in this specification.
|
Section 6.12.2). The 5G SUCI mechanism can not be used 1:1 for previous
|
||||||
|
generations of cellular networks as it relies on extending the
|
||||||
|
subscriber identity from the small, 15-decimal-digit IMSI to a much
|
||||||
|
larger SUPI (Subscriber Permanent Identifier) only available in 5G.
|
||||||
|
|
||||||
|
No mechanism for increasing subscriber identity and location privacy on
|
||||||
|
the radio interface has been specified for the previous cellular
|
||||||
|
technologies 2G (GSM), 3G (UMTS) and 4G (LTE). Meanwhile, pure 5G
|
||||||
|
networks are and will remain rare for many years to come, as operators
|
||||||
|
have to support billions of deployed legacy pre-5G ME. Operating
|
||||||
|
combined 5G + previous technology networks enables the so-called
|
||||||
|
"downgrade attacks" where the attacker blocks access to 5G e.g. by means
|
||||||
|
of jamming/interference, and hence triggers the ME to use a previous
|
||||||
|
generation which is still susceptible to the attacks.
|
||||||
|
|
||||||
|
This specification proposes a different approach to conceal the
|
||||||
|
IMSI for legacy 2G, 3G and 4G networks.
|
||||||
|
|
||||||
=== Summary of Proposed Solution
|
=== Summary of Proposed Solution
|
||||||
|
|
||||||
The solution presented in this document is to periodically change the IMSI of
|
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)
|
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
|
or Home Subscriber Service (HSS). The next pseudonymous IMSI is sent to the SIM/USIM
|
||||||
via Short Message Service (SMS), then a SIM applet overwrites the IMSI of the
|
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
|
SIM/USIM with the new value. The only components in the network that need to be
|
||||||
network besides the SIM/USIM is the HLR/HSS, therefore it should be possible
|
changed in order to support this mechanism are the SIM/USIM and the
|
||||||
even for a Mobile Virtual Network Operator (MVNO) to deploy this privacy
|
HLR/HSS. All other elements (like BTS, NodeB, eNodeB, BSC, RNC, MME,
|
||||||
enhancement.
|
MSC/VLR, SGSN, GGSN, S-GW, P-GW, ...) remain as-is, without any changes
|
||||||
|
to their specification or implementation.
|
||||||
|
|
||||||
|
Constraining the required changes to only two elements in the network
|
||||||
|
enables quick adoption potential for the proposed mechanism.
|
||||||
|
|
||||||
|
Furthermore, as SIM/USIM and HLR/HSS are the only two elements under control
|
||||||
|
of a Mobile Virtual Network Operator (MVNO), this mechanism can be
|
||||||
|
deployed by a MVNO without any changes to the operators of the physical
|
||||||
|
infrastructure (MNO).
|
||||||
|
|
||||||
=== Summary of Existing Location Updating Procedures in RAN and CN
|
=== Summary of Existing Location Updating Procedures in RAN and CN
|
||||||
|
|
||||||
The subscriber's SIM is provisioned with the IMSI and cryptographic keys of a
|
Every subscriber's SIM/USIM is provisioned with the IMSI and secret
|
||||||
subscriber, after the subscriber was added with the same data to the HLR/HSS.
|
cryptographic keys (Ki or K+OP[c]). The same IMSI and key data is also provisioned
|
||||||
In the Remote Access Network (RAN), the IMSI is sent over the air interface and
|
into the HLR/HSS, the central subscriber database of a cellular network.
|
||||||
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
|
In a number of different situations, the IMSI is sent over the air
|
||||||
whether the SIM is attempting a Circuit Switched (CS) or Packet Switched (PS)
|
interface and back-haul towards the Core Network (CN), where it is
|
||||||
connection, but the principle is the same. This document uses 2G CS Location
|
validated by the HLR/HSS. The involved components vary by the generation
|
||||||
Updating for reference, as in <<figure-imsi-regular>>.
|
of the network and whether the SIM/USIM 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
|
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
|
needs an authentication challenge specific to the secret keys on the SIM/USIM to
|
||||||
authenticate the SIM, and looks the authentication challenges up by the IMSI.
|
authenticate the SIM/USIM, and looks the authentication challenges up by the IMSI.
|
||||||
If the VLR does not have any more authentication challenges for the IMSI (as it
|
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
|
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
|
authentication challenges from the HLR/HSS. Then the HLR/HSS verifies that the IMSI is
|
||||||
known and, if it is unknown, sends back an error that will terminate the
|
known and, if it is unknown, sends back an error that will terminate the
|
||||||
Location Updating procedure.
|
Location Updating procedure.
|
||||||
|
|
||||||
After the VLR found the authentication challenge, it authenticates the SIM, and
|
After the VLR found the authentication challenge, it authenticates the SIM/USIM, and
|
||||||
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
performs a Classmark Enquiry and Physical Channel Reconfiguration. Then the VLR
|
||||||
has the required information to finish the Location Updating, and continues
|
has the required information to finish the Location Updating, and continues
|
||||||
with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns
|
with Process Update_Location_HLR (3GPP TS 29.002). Afterwards, the VLR assigns
|
||||||
|
@ -63,6 +101,16 @@ 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
|
Reallocation Complete. In following Location Updates with the same MSC, the ME
|
||||||
sends the TMSI instead of the IMSI in the Location Updating Request.
|
sends the TMSI instead of the IMSI in the Location Updating Request.
|
||||||
|
|
||||||
|
However, the allocation of the TMSI is optional (the network may choose
|
||||||
|
to not perform it), and particularly at mobility changes across the
|
||||||
|
MSC/VLR boundary, or even across the PLMN boundary, the TMSI allocated
|
||||||
|
by the previouis network element may not be known, and an IMSI based
|
||||||
|
Location Updating procedure used.
|
||||||
|
|
||||||
|
Furthermore, at any given point in time, a legitimate network or a rogue
|
||||||
|
base station can inquire the IMSI from the ME using the "MM IDENTITY
|
||||||
|
REQUEST (IMSI)" command.
|
||||||
|
|
||||||
[[figure-imsi-regular]]
|
[[figure-imsi-regular]]
|
||||||
.Location Updating in 2G CS with IMSI
|
.Location Updating in 2G CS with IMSI
|
||||||
["mscgen"]
|
["mscgen"]
|
||||||
|
@ -123,16 +171,22 @@ msc {
|
||||||
<<<
|
<<<
|
||||||
== Required Changes
|
== Required Changes
|
||||||
|
|
||||||
[[hlr-imsi-pseudo-storage]]
|
This section covers the changes / enhancements required
|
||||||
=== Pseudonymous IMSI Storage in the HLR
|
compared to the existing 3GPP specifications.
|
||||||
|
|
||||||
The HLR must store up to two pseudonymous IMSIs (imsi_pseudo) and their related
|
[[hlr-imsi-pseudo-storage]]
|
||||||
counters (imsi_pseudo_i) per subscriber. Each subscriber initially has one
|
=== Pseudonymous IMSI Storage in the HLR/HSS
|
||||||
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 HLR/HSS must store up to two pseudonymous IMSIs (`imsi_pseudo`) and
|
||||||
The amount of available IMSIs must be higher than the amount of subscribers
|
their related counters (`imsi_pseudo_i`) per subscriber. Each subscriber
|
||||||
registered with the HLR. If the amount of available IMSIs is too short, the HLR
|
initially has one pseudonymous IMSI allocated. A subscriber has two
|
||||||
can delay assigning new pseudonymous IMSIs until new IMSIs are available again.
|
valid pseudonymous IMSIs only during the transition phase from the old
|
||||||
|
pseudonymous IMSI to the new one.
|
||||||
|
|
||||||
|
Subsequently, the amount of available IMSIs must be higher than the
|
||||||
|
amount of subscribers registered with the HLR/HSS. If the amount of
|
||||||
|
available IMSIs is too small, the HLR/HSS could delay assigning new
|
||||||
|
pseudonymous IMSIs until new IMSIs are available again.
|
||||||
|
|
||||||
.Examples for additional subscriber data in HLR
|
.Examples for additional subscriber data in HLR
|
||||||
[options="header"]
|
[options="header"]
|
||||||
|
@ -154,32 +208,46 @@ can delay assigning new pseudonymous IMSIs until new IMSIs are available again.
|
||||||
|
|
||||||
==== imsi_pseudo
|
==== imsi_pseudo
|
||||||
|
|
||||||
The value for imsi_pseudo is a random choice from the pool of available IMSIs
|
The value for `imsi_pseudo` is a random choice from the pool of available
|
||||||
that the HLR controls. The pseudonymous IMSI must not be used by any subscriber
|
IMSIs that the HLR/HSS controls. The pseudonymous IMSI must not be used
|
||||||
as pseudonymous IMSI yet, but may be the real IMSI of a subscriber.
|
by any subscriber as pseudonymous IMSI yet, but may be the real IMSI of
|
||||||
|
a subscriber.
|
||||||
|
|
||||||
[[hlr-imsi-pseudo-i]]
|
[[hlr-imsi-pseudo-i]]
|
||||||
==== imsi_pseudo_i
|
==== imsi_pseudo_i
|
||||||
|
|
||||||
The counter imsi_pseudo_i indicates how often a subscribers pseudonymous IMSI
|
The counter `imsi_pseudo_i` indicates how often a subscribers pseudonymous IMSI
|
||||||
was changed. The value is 1 for the first allocated pseudonymous IMSI of a
|
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,
|
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
|
the new `imsi_pseudo_i` value is increased by 1. The counter is used by the SIM/USIM
|
||||||
applet to detect and ignore outdated requests related to changing the
|
applet to detect and ignore outdated requests related to changing the
|
||||||
pseudonymous IMSI.
|
pseudonymous IMSI.
|
||||||
|
|
||||||
=== SIM Provisioning
|
=== SIM/USIM Provisioning
|
||||||
|
|
||||||
IMSI pseudonymization as specified by this document works with SIM and USIM.
|
IMSI pseudonymization as specified by this document works with
|
||||||
The HLR is allocating a pseudonymous IMSI for the subscriber. This pseudonymous
|
traditional SIM (used i 2G), as well as with USIM (used from 3G
|
||||||
IMSI is stored as IMSI on the subscriber's SIM instead of the real IMSI.
|
onwards).
|
||||||
|
|
||||||
|
The initial IMSI provisioned in the SIM/USIM is provisioned as the initial
|
||||||
|
pseudonymous IMSI in the HLR/HSS.
|
||||||
|
|
||||||
[[sim-app]]
|
[[sim-app]]
|
||||||
==== SIM applet
|
==== SIM applet
|
||||||
|
|
||||||
The SIM is provisioned with a SIM applet, which is able to change the IMSI once
|
SIM/USIM have long supported the installation and operation of
|
||||||
the next pseudonymous IMSI arrives from the HLR. A reference implementation is
|
additional applets on the card itself. The programming language and
|
||||||
provided in <<reference-src>>.
|
runtime environment for such applets is an implementation detail.
|
||||||
|
However, the industry has converged around JavaCards with related
|
||||||
|
additional APIs specific to SIM, UICC and USIM. Depending on the card
|
||||||
|
profile / provisioning, it is possible for such applets to access the
|
||||||
|
card file system and modify files on the card, such as the file storing
|
||||||
|
the IMSI.
|
||||||
|
|
||||||
|
A SIM/USIM compatible with this specification is provisioned with a SIM
|
||||||
|
applet, which is able to change the IMSI once the next pseudonymous IMSI
|
||||||
|
arrives from the HLR/HSS. A reference implementation is provided in
|
||||||
|
<<reference-src>>.
|
||||||
|
|
||||||
===== Counter Storage
|
===== Counter Storage
|
||||||
|
|
||||||
|
@ -206,18 +274,18 @@ The following counter variables are stored in the SIM applet.
|
||||||
===== Switch to Next Pseudonymous IMSI
|
===== Switch to Next Pseudonymous IMSI
|
||||||
|
|
||||||
The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section
|
The SIM applet registers to a suitable SMS trigger (3GPP TS 43.019, Section
|
||||||
6.2). When an SMS from the HLR in the structure of <<sms-structure>> arrives,
|
6.2). When an SMS from the HLR/HSS in the structure of <<sms-structure>> arrives,
|
||||||
the applet must verify that the SMS is not outdated by comparing imsi_pseudo_i
|
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
|
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,
|
(initially 1 as in <<hlr-imsi-pseudo-i>>). The new value must be higher,
|
||||||
otherwise the SMS should not be processed further.
|
otherwise the SMS should not be processed further.
|
||||||
|
|
||||||
The SIM applet registers a timer with min_sleep_time from the SMS. When the
|
The SIM applet registers a timer with min_sleep_time from the SMS. When the
|
||||||
timer triggers, EF~IMSI~ of the SIM is overwritten with the new pseudonymous
|
timer triggers, EF~IMSI~ of the SIM/USIM is overwritten with the new pseudonymous
|
||||||
IMSI. The TMSI and related data (EF~LOCI~, EF~PSLOCI~) and ciphering keys
|
IMSI. The TMSI and related data (EF~LOCI~, EF~PSLOCI~) and ciphering keys
|
||||||
(EF~Kc~, EF~KcGPRS~, EF~Keys~, EF~KeysPS~) are invalidated (see 3GPP TS
|
(EF~Kc~, EF~KcGPRS~, EF~Keys~, EF~KeysPS~) are invalidated (see 3GPP TS
|
||||||
31.102). The current imsi_pseudo_i from the SMS is stored in the SIM applet
|
31.102). The current `imsi_pseudo_i` from the SMS is stored in the
|
||||||
to compare it with the next SMS. imsi_pseudo_lu is reset to 0. Afterwards,
|
SIM applet to compare it with the next SMS. `imsi_pseudo_lu` is reset to 0. Afterwards,
|
||||||
the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed
|
the EF~IMSI~ changing procedure in 3GPP TS 11.14, Section 6.4.7.1 is executed
|
||||||
to apply the new IMSI.
|
to apply the new IMSI.
|
||||||
|
|
||||||
|
@ -233,8 +301,8 @@ an attacker to track the subscriber by their pseudonymous IMSI. Therefore the
|
||||||
SIM applet should warn the subscriber if the pseudonymous IMSI does not change.
|
SIM applet should warn the subscriber if the pseudonymous IMSI does not change.
|
||||||
|
|
||||||
The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS
|
The SIM applet registers to EVENT_EVENT_DOWNLOAD_LOCATION_STATUS (3GPP TS
|
||||||
03.19, Section 6.2) and increases imsi_pseudo_lu by 1 when the event is
|
03.19, Section 6.2) and increases `imsi_pseudo_lu` by 1 when the event is
|
||||||
triggered. If imsi_pseudo_lu reaches imsi_pseudo_lu_max, the SIM applet
|
triggered. If `imsi_pseudo_lu` reaches `imsi_pseudo_lu_max`, the SIM applet
|
||||||
displays a warning to the subscriber.
|
displays a warning to the subscriber.
|
||||||
|
|
||||||
[[process-update-location-hlr]]
|
[[process-update-location-hlr]]
|
||||||
|
@ -281,7 +349,7 @@ msc {
|
||||||
|
|
||||||
==== Update Location Request
|
==== Update Location Request
|
||||||
|
|
||||||
When Update Location Request arrives, the HLR does not look up the subscriber
|
When Update Location Request arrives, the HLR/HSS does not look up the subscriber
|
||||||
by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has
|
by the IMSI, but by the pseudonymous IMSI instead. Unless the subscriber has
|
||||||
two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the
|
two pseudonymous IMSI allocated and used the new pseudonymous IMSI in the
|
||||||
Update Location Request, this is followed by the existing logic to continue
|
Update Location Request, this is followed by the existing logic to continue
|
||||||
|
@ -290,8 +358,8 @@ with Insert Subscriber Data Request.
|
||||||
===== Update Location Request With New Pseudonymous IMSI
|
===== Update Location Request With New Pseudonymous IMSI
|
||||||
|
|
||||||
If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was
|
If the subscriber has two pseudonymous IMSIs allocated, and the newer entry was
|
||||||
used (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), this section applies.
|
used (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), this section applies.
|
||||||
The older pseudonymous IMSI is deallocated in the HLR. This is done as early
|
The older pseudonymous IMSI is deallocated in the HLR/HSS. This is done as early
|
||||||
as possible, so the timeframe where two pseudonymous IMSI are allocated for one
|
as possible, so the timeframe where two pseudonymous IMSI are allocated for one
|
||||||
subscriber is short.
|
subscriber is short.
|
||||||
|
|
||||||
|
@ -303,7 +371,7 @@ to continue with Insert Subscriber Data Request.
|
||||||
===== Update Location Request With Old Pseudonymous IMSI
|
===== Update Location Request With Old Pseudonymous IMSI
|
||||||
|
|
||||||
If the subscriber has two pseudonymous IMSIs allocated, and the older entry was
|
If the subscriber has two pseudonymous IMSIs allocated, and the older entry was
|
||||||
used (lower imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
|
used (lower `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>), the newer entry is _not_
|
||||||
deallocated. This could lock out the subscriber from the network if the SMS
|
deallocated. This could lock out the subscriber from the network if the SMS
|
||||||
with the new pseudonymous IMSI arrives with a delay.
|
with the new pseudonymous IMSI arrives with a delay.
|
||||||
|
|
||||||
|
@ -315,19 +383,19 @@ Next_Pseudo_IMSI_Timer starts.
|
||||||
==== Next_Pseudo_IMSI_Timer Expires
|
==== Next_Pseudo_IMSI_Timer Expires
|
||||||
|
|
||||||
If the subscriber has only one pseudonymous IMSI allocated, and the amount of
|
If the subscriber has only one pseudonymous IMSI allocated, and the amount of
|
||||||
available IMSIs in the HLR is high enough, a second pseudonymous IMSI and
|
available IMSIs in the HLR/HSS is high enough, a second pseudonymous IMSI and
|
||||||
related imsi_pseudo_i gets allocated for the subscriber (as described in
|
related `imsi_pseudo_i` gets allocated for the subscriber (as described in
|
||||||
<<hlr-imsi-pseudo-storage>>).
|
<<hlr-imsi-pseudo-storage>>).
|
||||||
|
|
||||||
If the subscriber still has only one pseudonymous IMSI, because not enough
|
If the subscriber still has only one pseudonymous IMSI, because not enough
|
||||||
IMSIs were available in the HLR, the process is aborted here and no SMS with
|
IMSIs were available in the HLR/HSS, the process is aborted here and no SMS with
|
||||||
a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a
|
a next pseudonymous IMSI is sent to the subscriber. The subscriber will get a
|
||||||
new pseudonymous IMSI during the next Location Updating Procedure, if the HLR
|
new pseudonymous IMSI during the next Location Updating Procedure, if
|
||||||
has enough IMSIs available at that point.
|
the HLR/HSS has enough IMSIs available at that point.
|
||||||
|
|
||||||
An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous
|
An SMS is sent to the SMS - Service Centre (SMS-SC) with the newer pseudonymous
|
||||||
IMSI (higher imsi_pseudo_i, see <<hlr-imsi-pseudo-i>>) and related
|
IMSI (higher `imsi_pseudo_i`, see <<hlr-imsi-pseudo-i>>) and related
|
||||||
imsi_pseudo_i value.
|
`imsi_pseudo_i` value.
|
||||||
|
|
||||||
[[sms-structure]]
|
[[sms-structure]]
|
||||||
==== Next Pseudonymous IMSI SMS Structure
|
==== Next Pseudonymous IMSI SMS Structure
|
||||||
|
@ -368,9 +436,9 @@ Padding at the end, should be filled with 1111 as in the TBCD specification.
|
||||||
|
|
||||||
=== Next Pseudonymous IMSI SMS is Lost
|
=== Next Pseudonymous IMSI SMS is Lost
|
||||||
|
|
||||||
If the SMS with the next pseudonymous IMSI does not arrive, the SIM will start
|
If the SMS with the next pseudonymous IMSI does not arrive, the SIM/USIM will start
|
||||||
the next Location Updating Procedure with the old pseudonymous IMSI. Because
|
the next Location Updating Procedure with the old pseudonymous IMSI. Because
|
||||||
the HLR has both the old and the new pseudonymous IMSI allocated at this point,
|
the HLR/HSS has both the old and the new pseudonymous IMSI allocated at this point,
|
||||||
the subscriber is not locked out of the network.
|
the subscriber is not locked out of the network.
|
||||||
|
|
||||||
=== Next Pseudonymous IMSI SMS Arrives Out of Order
|
=== Next Pseudonymous IMSI SMS Arrives Out of Order
|
||||||
|
@ -379,7 +447,7 @@ The next pseudonymous IMSI SMS may arrive out of order. Either, because the
|
||||||
network is not able to deliver them in order, or even because an attacker would
|
network is not able to deliver them in order, or even because an attacker would
|
||||||
perform a replay attack.
|
perform a replay attack.
|
||||||
|
|
||||||
If the SMS arrives out of order, the imsi_pseudo_i counter will not be higher
|
If the SMS arrives out of order, the `imsi_pseudo_i` counter will not be higher
|
||||||
than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet
|
than the value the SIM applet (<<sim-app>>) has stored. Therefore, the applet
|
||||||
will discard the message and the subscriber is not locked out of the network.
|
will discard the message and the subscriber is not locked out of the network.
|
||||||
|
|
||||||
|
@ -406,11 +474,11 @@ message on the Broadcast Control Channel (BCCH), see 3GPP TS 44.018 Section
|
||||||
When deploying the IMSI pseudonymization, the operator should make sure that
|
When deploying the IMSI pseudonymization, the operator should make sure that
|
||||||
the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified
|
the next pseudonymous IMSI SMS (<<sms-structure>>) cannot be read or modified
|
||||||
by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the
|
by third parties. Otherwise, the next pseudonymous IMSI is leaked, and if the
|
||||||
pseudonymous IMSI in the SMS was changed, the SIM would be locked out of the
|
pseudonymous IMSI in the SMS was changed, the SIM/USIM would be locked out of the
|
||||||
network.
|
network.
|
||||||
|
|
||||||
The safest way to protect the next pseudonymous IMSI SMS is a layer of end to
|
The safest way to protect the next pseudonymous IMSI SMS is a layer of end to
|
||||||
end encryption from the HLR to the SIM. The existing means for OTA SMS
|
end encryption from the HLR/HSS to the SIM/USIM. The existing means for OTA SMS
|
||||||
security (3GPP TS 23.048) provide mechanisms for integrity protection,
|
security (3GPP TS 23.048) provide mechanisms for integrity protection,
|
||||||
confidentiality as well as replay protection and must be implemented when using
|
confidentiality as well as replay protection and must be implemented when using
|
||||||
IMSI pseudonymization.
|
IMSI pseudonymization.
|
||||||
|
@ -441,7 +509,7 @@ source code under the Apache-2.0 license at:
|
||||||
|
|
||||||
https://osmocom.org/projects/imsi-pseudo
|
https://osmocom.org/projects/imsi-pseudo
|
||||||
|
|
||||||
The HLR modifications described in <<hlr-imsi-pseudo-storage>> and
|
The HLR/HSS modifications described in <<hlr-imsi-pseudo-storage>> and
|
||||||
<<process-update-location-hlr>> were implemented for reference in OsmoHLR from
|
<<process-update-location-hlr>> were implemented for reference in OsmoHLR from
|
||||||
the Osmocom project, licensed under AGPL-3.0. Information about the source code
|
the Osmocom project, licensed under AGPL-3.0. Information about the source code
|
||||||
and related branches for IMSI pseudonymization can be found at the above URL as
|
and related branches for IMSI pseudonymization can be found at the above URL as
|
||||||
|
|
Loading…
Reference in New Issue