remove text replaced by specification

laforge/spec
Oliver Smith 3 years ago
parent 0feaa89ab9
commit 247c875973
  1. 144
      README.md
  2. 28
      docs/specification.md

@ -5,146 +5,4 @@ mobile subscriber on the radio interface in a 2G, 3G, 4G network.
Homepage: https://osmocom.org/projects/imsi-pseudo/wiki
## How it works
The first pseudo IMSI gets allocated in the HLR, as the SIM card is
provisioned. After that pseudo IMSI is used for the first time in location
update, the HLR waits for some time, then decides the next pseudo IMSI and
sends it together with a delay value as SMS to the SIM. The SIM applet receives
the SMS and waits the specified delay. Then it overwrites its current IMSI with
the new one, marks the TMSI as invalid, and initiates the next location update.
Afterwards, the process repeats.
```
HLR <-> SIM LOCATION UPDATE, imsi_pseudo=200
(time passes)
HLR -> SIM NEW PSEUDO IMSI, imsi_pseudo=123, delay=60
(time passes until the SMS arrives)
(SIM applet waits 60 seconds)
HLR <-> SIM LOCATION UPDATE, imsi_pseudo=123
...
```
## In detail
### 1. Provisioning the SIM
The HLR allocates a new pseudo IMSI as random choice from the pool of available
IMSIs. The pseudo IMSI must not be used by any other subscriber as pseudo IMSI,
but may be the real IMSI of another subscriber. The subscriber-specific counter
imsi_pseudo_i is 0 for the first allocated IMSI for that subscriber.
| id | imsi | imsi_pseudo | imsi_pseudo_i |
|------|--------|---------------|---------------|
| 1 | 100 | 200 | 0 |
The pseudo IMSI is saved to the SIM as IMSI, instead of the real IMSI. The SIM
is also provisioned with the IMSI pseudonymization applet.
### 2. Successful Location Update with pseudo IMSI
a) If this was the first Location Update after provisioning the SIM, the
subscriber has only one pseudo IMSI allocated. The HLR waits for some time.
Then it allocates the next pseudo IMSI from the pool of available IMSIs (as in
1., but with imsi_pseudo_i increased by one). The HLR sends the new
pseudo IMSI, the imsi_pseudo_i and a random delay value in one SMS to the SIM.
The random delay is how long the SIM applet should wait before changing the
IMSI. This delay prevents easy correlation of the arrival of the SMS with the
Location Update that will follow in 3. by the SIM. Due to other latencies in
the network, this is a minimum delay. At this point, the subscriber has two
allocated pseudo IMSIs:
| id | imsi | imsi_pseudo | imsi_pseudo_i |
|------|--------|---------------|---------------|
| 1 | 100 | 200 | 0 |
| 2 | 100 | 123 | 1 |
b) If this was not the first Location Update after provisioning a new SIM, the
subscriber already has two pseudo IMSIs allocated when doing the Location
Update. The HLR compares imsi_pseudo_i to find out if the Location Update was
done with the newer or older pseudo IMSI.
If the older pseudo IMSI was used, then the SIM applet was not able to set the
new IMSI. This may be caused by an SMS arriving late, possibly even months
after it was sent in case the UE was without power for a long period of time.
Therefore the HLR cannot deallocate the newer pseudo IMSI without risking that
the SIM would configure that IMSI and then be locked out (unable to do any
further location updates). Instead, the HLR proceeds like in a), but sends the
same unused new pseudo IMSI again instead of allocating a new one.
If the newer pseudo IMSI was used, the SIM applet has successfully set the new
IMSI. The HLR deallocates the old pseudo IMSI and sends a Purge MS request to
the VLR with the old pseudo IMSI. Then the HLR proceeds like in a).
### 3. Arrival of the SMS
The SIM applet verifies, that imsi_pseudo_i is higher than the last
imsi_pseudo_i it has seen (initially: 0). If that is not the case, it discards
the message.
The SIM applet registers a timer to wait the specified delay. When the timer
expires, the applet updates the last imsi_pseudo_i value that it has seen. Then
it overwrites the IMSI with the next pseudo IMSI and invalidates the TMSI and
Kc. The applet triggers a refresh, which causes the SIM to do a new Location
Update with the new IMSI.
It is important, that the SIM does not invoke the IMSI detach procedure (TS
04.08 Section 4.3.4). This is controlled by the network. Otherwise it becomes
trivial to correlate the detach of the old IMSI with the attach or Location
Update of the new IMSI.
## Notes
### What if the SMS gets lost?
Both the old and the new pseudo IMSI entry exist in the HLR.
The SIM will use the old pseudo IMSI in the next Location Update. The HLR will
try to send _the same_ new pseudo IMSI with the same new imsi_pseudo_i, as soon
as the next Location Update is complete.
### What if the SMS arrives late?
The imsi_pseudo_i counter will not be higher than the value the SIM applet
already knows. Therefore, the applet will discard the message.
### Warning the user if SMS don't arrive
An attacker could possibly block the SMS from arriving at the SIM applet. In
that case, the SIM would continue using the old pseudo IMSI indefinitely.
We can count the location updates done with the same pseudo IMSI in the SIM
applet, and warn the user if the same pseudo IMSI has been used more than N
(e.g. 5) times.
### End2end encryption
When deploying the IMSI pseudonymization, the operator should make sure that
the pseudo IMSI related SMS between the HLR and the SIM cannot be read or
modified by third parties. Otherwise, the next pseudonymous IMSI is leaked, and
in case of modifying the IMSI in the SMS, the SIM may be locked out of the
network.
OTA SMS are usually encrypted and authenticated (TS 03.48), with algorithms and
key lengths that the operator chooses (depending on the SIM and how it is
configured).
It was considered to add an additional layer of end2end encryption for the
pseudonymized IMSIs on top, but this is out-of-scope for this project. For
reference, one could pre-provision a random "imsi_pseudo_key" with the SIM
card, store it in the pseudo IMSI table in the HLR, and deploy a new encryption
key together with each new pseudo IMSI, attached to the SMS.
### User-configurable minimum duration between IMSI changes
It may be desirable to let users configure their minimum duration between IMSI
changes. This allows people with a high privacy requirement to switch their
pseudonymous IMSI more often, and it allows the IMSI change to happen less
often if it is distracting to the user. The latter depends on the phone's
software, for example:
* A Samsung GT-I9100 Galaxy SII smartphone with Android 4.0.3 displays a
message at the bottom of the screen for about 5 seconds, but the user
interface remains usable.
* A Samsung GT-E1200 feature phone displays a waiting screen for 16 to 17
seconds and is unusable during that time.
Find the specification in the docs subdir.

@ -1,28 +0,0 @@
# [WIP] Make IMSI Pseudonymization an optional extension of 3GPP TS
NOTE: this file is deprecated, it will be replaced by imsi-pseudo-spec.adoc.
Relevant specs:
* 3GPP TS 23.008: Organization of subscriber data
* Add pseudo IMSI and pseudo_imsi_i optionally to be saved in the HLR
* "Process Update_Location_HLR" of TS 09.02
* Cancel location in old VLR/SGSN if IMSI pseudonymization is enabled, and a
previous pseudonymous IMSI exists for the subscriber
Optional additions we need to make, and where to make them:
* Initial provisioning of the SIM: can optionally have a pseudo IMSI
* During location update, the HLR uses the pseudo IMSI for all communication
with the VLR / MSC
* Is there anything to update? We just replace the IMSI, so the SIM and the
VLR / MSC don't act any different
* After successful location update:
* See 2. in README.md
TODO:
* extend the list above with the exact sections of the spec, where the new
information should be placed
* Is there a spec for SIM applets, or do we put the SIM applet behaviour in the
regular spec for SIM cards, or mention its behavior in the location update
related change?
* describe everything in detail, fill in the full contents for the SMS etc.
Loading…
Cancel
Save