Revision 65b41130
Added by osmith about 4 years ago
README.md | ||
---|---|---|
1 |
# Osmocom IMSI Pseudonymization Project |
|
2 |
|
|
3 |
Specification and reference SIM applet implementation to conceal the IMSI of a |
|
4 |
mobile subscriber on the radio interface in a 2G, 3G, 4G network. |
|
5 |
|
|
6 |
Homepage: https://osmocom.org/projects/imsi-pseudo/wiki |
|
7 |
|
|
8 |
## How it works |
|
9 |
|
|
10 |
The first pseudo IMSI gets allocated, as the SIM card is provisioned. After |
|
11 |
that pseudo IMSI is used for the first time in location update, the HLR decides |
|
12 |
the next pseudo IMSI and sends it as SMS to the SIM. The SIM applet overwrites |
|
13 |
its current IMSI with the new one, and uses it in the next location update. |
|
14 |
Afterwards, the HLR will generate the next IMSI and so on. |
|
15 |
|
|
16 |
``` |
|
17 |
HLR <-> SIM LOCATION UPDATE, imsi_pseudo=200 |
|
18 |
HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123 |
|
19 |
HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123 |
|
20 |
(time passes) |
|
21 |
HLR <-> SIM LOCATION UPDATE, imsi_pseudo=123 |
|
22 |
... |
|
23 |
``` |
|
24 |
|
|
25 |
## In Detail |
|
26 |
|
|
27 |
1. The HLR has a table of allocated pseudo IMSIs. When provisioning a new SIM, |
|
28 |
it randomly decides a new pseudo IMSI. There must be no existing entry in the |
|
29 |
table with the same pseudo IMSI in the imsi_pseudo column, but the pseudo IMSI |
|
30 |
may be the real IMSI of an existing entry. |
|
31 |
|
|
32 |
| id | imsi | imsi_pseudo | session_id | |
|
33 |
|------|--------|---------------|--------------| |
|
34 |
| 1 | 100 | 200 | 0 | |
|
35 |
|
|
36 |
(Other interesting fields to store in the table may be a boolean for |
|
37 |
"provisioned", the allocation date and usage count. The usage count would |
|
38 |
increase whenever the SIM does a successful Location Update with that pseudo |
|
39 |
IMSI.) |
|
40 |
|
|
41 |
2. The SIM does a successful Location Update with its current pseudo IMSI. |
|
42 |
|
|
43 |
(Clean up: if the ACK from the SIM card in step 4 did not arrive in a previous |
|
44 |
provisioning of a new pseudo IMSI, and the SIM has connected with the newer |
|
45 |
pseudo IMSI entry, the old pseudo IMSI entry gets deleted now.) |
|
46 |
|
|
47 |
Then the HLR creates a new entry with a new pseudo IMSI (generated as described |
|
48 |
in 1.), and with the session_id increased by one. |
|
49 |
|
|
50 |
| id | imsi | imsi_pseudo | session_id | |
|
51 |
|------|--------|---------------|--------------| |
|
52 |
| 1 | 100 | 200 | 0 | |
|
53 |
| 2 | 100 | 123 | 1 | |
|
54 |
|
|
55 |
The new information is encoded in an SMS and sent to the SIM. |
|
56 |
|
|
57 |
``` |
|
58 |
HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123 |
|
59 |
``` |
|
60 |
|
|
61 |
3. The SIM applet verifies, that the session_id is higher than the last |
|
62 |
session_id it has seen (initially: 0). If that is not the case, it discards the |
|
63 |
message. |
|
64 |
|
|
65 |
The SIM applet writes the new pseudo IMSI and session_id to the SIM card, |
|
66 |
overwriting the old data. It acknowledges the new data with a SMS back to the |
|
67 |
HLR: |
|
68 |
|
|
69 |
``` |
|
70 |
HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123 |
|
71 |
``` |
|
72 |
|
|
73 |
4. The HLR verifies, that an entry with the session_id and imsi_pseudo from the |
|
74 |
NEW PSEUDO IMSI RESP ACK message exists in the table. If not, it discards the |
|
75 |
message. |
|
76 |
|
|
77 |
HLR it deletes the old entry with the same IMSI (in the example: the one with |
|
78 |
imsi_pseudo=200). |
|
79 |
|
|
80 |
| id | imsi | imsi_pseudo | session_id | |
|
81 |
|------|--------|---------------|--------------| |
|
82 |
| 2 | 100 | 123 | 1 | |
|
83 |
|
|
84 |
## Messages getting lost |
|
85 |
|
|
86 |
### What if "NEW PSEUDO IMSI REQ" gets lost? |
|
87 |
|
|
88 |
Both the old and the new pseudo IMSI entry exist in the HLR. |
|
89 |
|
|
90 |
The SIM will use the old pseudo IMSI in the next location update. The HLR will |
|
91 |
try to send _the same_ new pseudo IMSI with the same new session_id, as soon |
|
92 |
as the next location update is complete. |
|
93 |
|
|
94 |
### What if "NEW PSEUDO IMSI RESP" gets lost? |
|
95 |
|
|
96 |
Both the old and the new pseudo IMSI entry exist in the HLR. |
|
97 |
|
|
98 |
The SIM will use the new pseudo IMSI in the next location update. The HLR will |
|
99 |
then clean up the old pseudo IMSI entry, and proceed with generating a new |
|
100 |
pseudo IMSI entry and sending it to the SIM, as usually. |
|
101 |
|
|
102 |
## Messages arriving late |
|
103 |
|
|
104 |
### What if "NEW PSEUDO IMSI REQ" arrives late? |
|
105 |
|
|
106 |
The session_id will not be higher than the session_id, which the SIM card |
|
107 |
already knows. Therefore, the applet will discard the message. |
|
108 |
|
|
109 |
### What if "NEW PSEUDO IMSI RESP" arrives late? |
|
110 |
|
|
111 |
Session_id and imsi_pseudo from the message will not match what's in the HLR |
|
112 |
database, so HLR will discard the message. |
|
113 |
|
|
114 |
## Warning the user if SMS don't arrive |
|
115 |
|
|
116 |
An attacker could possibly block the SMS with NEW PSEUDO IMSI REQ from arriving |
|
117 |
at the SIM applet. In that case, the SIM would continue using the old pseudo |
|
118 |
IMSI indefinitely. |
|
119 |
|
|
120 |
We could possibly count the location updates done with the same pseudo IMSI in |
|
121 |
the SIM applet, and warn the user if the same pseudo IMSI has been used more |
|
122 |
than N (e.g. 5) times. |
|
123 |
|
|
124 |
(Could be possible by listening to EVENT_DOWNLOAD_LOCATION_STATUS?) |
|
125 |
|
|
126 |
## End2end encryption |
|
127 |
|
|
128 |
When deploying the IMSI pseudonymization, the operator should make sure that |
|
129 |
the pseudo IMSI related SMS between the HLR and the SIM cannot be read or |
|
130 |
modified by third parties. Otherwise, the next pseudonymous IMSI is leaked, and |
|
131 |
in case of modifying the IMSI in the SMS, the SIM may be locked out of the |
|
132 |
network. |
|
133 |
|
|
134 |
OTA SMS are usually encrypted and authenticated (TS 03.48), with algorithms and |
|
135 |
key lengths that the operator chooses (depending on the SIM and how it is |
|
136 |
configured). |
|
137 |
|
|
138 |
It was considered to add an additional layer of end2end encryption for the |
|
139 |
pseudonymized IMSIs on top, but this is out-of-scope for this project. For |
|
140 |
reference, once could pre-provision a random "imsi_pseudo_key" with the SIM |
|
141 |
card, store it in the pseudo IMSI table in the HLR, and deploy a new encryption |
|
142 |
key together with each new pseudo IMSI, attached to the NEW PSEUDO IMSI REQ. |
Also available in: Unified diff
README.md: describe current approach
Based on my "Approach C" in OS#4400.