cellular-infrastructure
/
imsi-pseudo
mirror of https://gerrit.osmocom.org/imsi-pseudo
9
0
Fork 0
Code Issues Releases Wiki Activity

docs: update to feedback from Neels 

Most importantly, there is no ACK SMS anymore, because the next LU is
the implicit ACK. While at it, I've filled in the first TS we probably
need to update.

Related: OS#440
This commit is contained in:
Oliver Smith 2020-02-26 15:20:15 +01:00
parent 15c3bfb49f
commit 5e62dbacd1
2 changed files with 76 additions and 113 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

154
README.md
View File

@ -7,123 +7,109 @@ Homepage: https://osmocom.org/projects/imsi-pseudo/wiki
## How it works ## How it works
The first pseudo IMSI gets allocated, as the SIM card is provisioned. After The first pseudo IMSI gets allocated in the HLR, as the SIM card is
that pseudo IMSI is used for the first time in location update, the HLR decides provisioned. After that pseudo IMSI is used for the first time in location
the next pseudo IMSI and sends it as SMS to the SIM. The SIM applet overwrites update, the HLR waits for some time, then decides the next pseudo IMSI and
its current IMSI with the new one, and uses it in the next location update. sends it together with a delay value as SMS to the SIM. The SIM applet receives
Afterwards, the HLR will generate the next IMSI and so on. 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.
**FIXME:** details below need updating, see [OS#4400](https://osmocom.org/issues/4400). Afterwards, the process repeats.
``` ```
HLR <-> SIM LOCATION UPDATE, imsi_pseudo=200 HLR <-> SIM LOCATION UPDATE, imsi_pseudo=200
HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123
HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123
(time passes) (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 HLR <-> SIM LOCATION UPDATE, imsi_pseudo=123
... ...
``` ```
## In Detail ## In Detail
1. The HLR has a table of allocated pseudo IMSIs. When provisioning a new SIM, 1. Provisioning the SIM
it randomly decides a new pseudo IMSI. There must be no existing entry in the
table with the same pseudo IMSI in the imsi_pseudo column, but the pseudo IMSI
may be the real IMSI of an existing entry.
| id | imsi | imsi_pseudo | session_id | 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,
| 1 | 100 | 200 | 0 | 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.
(Other interesting fields to store in the table may be a boolean for | id | imsi | imsi_pseudo | imsi_pseudo_i |
"provisioned", the allocation date and usage count. The usage count would |------|--------|---------------|---------------|
increase whenever the SIM does a successful Location Update with that pseudo | 1 | 100 | 200 | 0 |
IMSI.)
2. The SIM does a successful Location Update with its current pseudo IMSI. 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.
(Clean up: if the ACK from the SIM card in step 4 did not arrive in a previous 2. Successful Location Update with pseudo IMSI
provisioning of a new pseudo IMSI, and the SIM has connected with the newer
pseudo IMSI entry, the old pseudo IMSI entry gets deleted now.)
Then the HLR creates a new entry with a new pseudo IMSI (generated as described a) If this was the first Location Update after provisioning the SIM, the
in 1.), and with the session_id increased by one. 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.
| id | imsi | imsi_pseudo | session_id | 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
| 1 | 100 | 200 | 0 | Location Update that will follow in 3. by the SIM. Due to other latencies in
| 2 | 100 | 123 | 1 | the network, this is a minimum delay. At this point, the subscriber has two
allocated pseudo IMSIs:
The new information is encoded in an SMS and sent to the SIM. | 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
HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123 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.
3. The SIM applet verifies, that the session_id is higher than the last If the older pseudo IMSI was used, then the SIM applet was not able to set the
session_id it has seen (initially: 0). If that is not the case, it discards the new IMSI. This may be caused by an SMS arriving late, possibly even months
message. 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.
The SIM applet writes the new pseudo IMSI and session_id to the SIM card, If the newer pseudo IMSI was used, the SIM applet has successfully set the new
overwriting the old data. It acknowledges the new data with a SMS back to the IMSI. The HLR deallocates the old pseudo IMSI and sends a Purge MS request to
HLR: the VLR with the old pseudo IMSI. Then the HLR proceeds like in a).
``` 3. Arrival of the SMS
HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123
```
4. The HLR verifies, that an entry with the session_id and imsi_pseudo from the The SIM applet verifies, that imsi_pseudo_i is higher than the last
NEW PSEUDO IMSI RESP ACK message exists in the table. If not, it discards the imsi_pseudo_i it has seen (initially: 0). If that is not the case, it discards
message. the message.
HLR it deletes the old entry with the same IMSI (in the example: the one with The SIM applet registers a timer to wait the specified delay. When the timer
imsi_pseudo=200). 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.
| id | imsi | imsi_pseudo | session_id | ### What if the SMS gets lost?
|------|--------|---------------|--------------|
| 2 | 100 | 123 | 1 |
## Messages getting lost
### What if "NEW PSEUDO IMSI REQ" gets lost?
Both the old and the new pseudo IMSI entry exist in the HLR. 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 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 session_id, as soon try to send _the same_ new pseudo IMSI with the same new imsi_pseudo_i, as soon
as the next location update is complete. as the next Location Update is complete.
### What if "NEW PSEUDO IMSI RESP" gets lost? ### What if the SMS arrives late?
Both the old and the new pseudo IMSI entry exist in the HLR. The imsi_pseudo_i counter will not be higher than the value the SIM applet
The SIM will use the new pseudo IMSI in the next location update. The HLR will
then clean up the old pseudo IMSI entry, and proceed with generating a new
pseudo IMSI entry and sending it to the SIM, as usually.
## Messages arriving late
### What if "NEW PSEUDO IMSI REQ" arrives late?
The session_id will not be higher than the session_id, which the SIM card
already knows. Therefore, the applet will discard the message. already knows. Therefore, the applet will discard the message.
### What if "NEW PSEUDO IMSI RESP" arrives late?
Session_id and imsi_pseudo from the message will not match what's in the HLR
database, so HLR will discard the message.
## Warning the user if SMS don't arrive ## Warning the user if SMS don't arrive
An attacker could possibly block the SMS with NEW PSEUDO IMSI REQ from arriving An attacker could possibly block the SMS from arriving at the SIM applet. In
at the SIM applet. In that case, the SIM would continue using the old pseudo that case, the SIM would continue using the old pseudo IMSI indefinitely.
IMSI indefinitely.
We could possibly count the location updates done with the same pseudo IMSI in We can count the location updates done with the same pseudo IMSI in the SIM
the SIM applet, and warn the user if the same pseudo IMSI has been used more applet, and warn the user if the same pseudo IMSI has been used more than N
than N (e.g. 5) times. (e.g. 5) times.
(Could be possible by listening to EVENT_DOWNLOAD_LOCATION_STATUS?)
## End2end encryption ## End2end encryption
@ -141,4 +127,4 @@ 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 pseudonymized IMSIs on top, but this is out-of-scope for this project. For
reference, once could pre-provision a random "imsi_pseudo_key" with the SIM reference, once 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 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 NEW PSEUDO IMSI REQ. key together with each new pseudo IMSI, attached to the SMS.

35
docs/specification.md
View File

@ -1,41 +1,18 @@
# [WIP] Make IMSI Pseudonymization an optional extension of 3GPP TS # [WIP] Make IMSI Pseudonymization an optional extension of 3GPP TS
**FIXME:** needs to be updated, see [OS#4400](https://osmocom.org/issues/4400). Relevant specs:
* 3GPP TS 23.008: Organization of subscriber data
* Add pseudo IMSI and pseudo_imsi_i optionally to be saved in the HLR
Optional additions we need to make, and where to make them: Optional additions we need to make, and where to make them:
* Initial provisioning of the SIM: can optionally have a pseudo IMSI * Initial provisioning of the SIM: can optionally have a pseudo IMSI
* During location update, the HLR uses the pseudo IMSI for all communication * During location update, the HLR uses the pseudo IMSI for all communication
with the VLR / MSC 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: * After successful location update:
* HLR deallocates a subscriber's previous pseudo IMSI, if it exists, and the * See 2. in README.md
subscriber has done the location update with the newer pseudo IMSI entry.
This is the case, if the SIM applet acknowledged the new pseudo IMSI, but
its ACK SMS did not arrive at the HLR. There are at most two pseudo IMSIs
allocated for one subscriber.
* If there is just one pseudo IMSI for the subscriber (no new pseudo IMSI to
switch to), the HLR allocates a new pseudo IMSI, and increases the
session_id by one for that new pseudo IMSI, compared to the last pseudo
IMSI.
* The HLR sends the new pseudo IMSI, and the associated session_id, to the
SIM via SMS. No matter, if the new pseudo IMSI was just created, or if it
existed already.
* The SIM applet checks, if the session_id is greater than the one that it
has stored, and rejects the SMS otherwise. If the session_id is fine, it
overwrites the SIM's IMSI and session_id with the new data. Then the SIM
sends an ACK packet back to the HLR, containing both the new session_id and
the new pseudo IMSI.
* The HLR verifies the session_id and pseudo IMSI in the ACK packet, discards
the packet if it doesn't know both. If it was not discarded, the HLR
deallocates the old pseudo IMSI.
* When allocating and deallocating pseudo IMSIs, the HLR flushes information in
the VLR related to them, so an old TMSI does not point to the wrong pseudo
IMSI.
* The SIM applet registers EVENT_DOWNLOAD_LOCATION_STATUS, uses it to count the
location updates that were done with the same pseudo IMSI, and warns the user
if the pseudo IMSI did not change over several location updates. This means,
that for some reason, the SMS from the HLR are not arriving (e.g. because an
attacker is blocking them).
TODO: TODO:
* extend the list above with the exact sections of the spec, where the new * extend the list above with the exact sections of the spec, where the new