Feature #4400
Updated by osmith about 4 years ago
h3. Overview In contrary to previous approaches, the HLR decides the pseudo IMSI independently of the SIM applet. The first pseudo IMSI gets allocated, as the SIM card is provisioned. After that pseudo IMSI is used for the first time, the HLR decides the next pseudo IMSI and sends it as end-to-end encrypted message to the SIM. The SIM applet overwrites its current IMSI with the new one, and uses it in the next location update. Afterwards, the HLR will generate the next IMSI and so on. h3. Full session <pre> 2. HLR -> SIM NEW SESSION REQ, session_id=1 3. HLR <- SIM NEW SESSION RESP ACK, session_id=1 4. HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123, imsi_pseudo_key=(random blob 2) 3. 5. HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123 </pre> h3. In Detail 1. The HLR has a table of allocated pseudo IMSIs. When provisioning a new SIM, it randomly decides a new pseudo IMSI and pseudo IMSI key. 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. The pseudo IMSI key is randomly chosen and used for end2end encrypted SMS between the HLR and the SIM applet. The pseudo IMSI key changes whenever the pseudo IMSI changes. |_. id |_. imsi |_. imsi_pseudo |_. imsi_pseudo_key |_. session_id | | 1 | 100 | 200 | (random blob) | 0 | (Other interesting fields to store in the table may be a boolean for "provisioned", the allocation date and usage count. The usage count would increase whenever the SIM does a successful Location Update with that pseudo IMSI.) 2. The After the SIM does a successful Location Update with its current pseudo IMSI. IMSI, the HLR will deliver a new pseudo IMSI via SMS to the SIM applet. (Clean up: if In preparation, a new session with an increased session ID must be established. This allows catching messages that arrive late, and we do not end up storing an IMSI in the ACK from SIM that the HLR suggested at one point but does not have allocated anymore. The session ID would be stored in the _subscriber_ table. HLR increases the session ID by one and sends a NEW SESSION REQ as SMS with the new session ID to the SIM. The SMS is encrypted with the IMSI_PSEUDO_KEY of the IMSI_PSEUDO that was used in the location update. <pre> HLR -> SIM card NEW SESSION REQ, session_id=1 </pre> 3. The SIM applet decrypts the SMS, verifies that the session_id counter is higher than the previous session_id it had stored in step 4 did the SIM. If that is not arrive the case, it discards the message. If the session_id is higher, it stores it in the SIM and answers with NEW SESSION RESP. The SMS is encrypted with IMSI_PSEUDO_KEY. <pre> HLR <- SIM NEW SESSION RESP ACK, session_id=1 </pre> 4. The new session is established. Clean up: if a previous provisioning of a new pseudo IMSI, IMSI has gone wrong in step 5. or 6., then we would have two pseudo IMSIs allocated in the database, the one that is currently in use, and either the previous pseudo IMSI or the new pseudo IMSI that was not acknowledged by the SIM has connected with applet. After establishing the newer session, it is clear, which pseudo IMSI entry, is currently in use, and that the SIM applet would not accept an old SMS provisioning the left over pseudo IMSI SIM in the table, because the session id would not match. The HLR deletes the left over entry gets deleted now.) now, if it exists. This mechanism makes sure, that we never have more than two pseudo IMSIs allocated per real subscriber. Then After clean up, the HLR creates a new entry with a new decides the next pseudo IMSI (as described in 1.) and imsi_pseudo_key (both generated generates a new imsi_pseudo_key. Both get added as described in 1.), and with new entry to the session_id increased by one. table: |_. id |_. imsi |_. imsi_pseudo |_. imsi_pseudo_key |_. session_id | | 1 | 100 | 200 | (random blob) | 0 | | 2 | 100 | 123 | (random blob 2) | 1 | The new information is encoded in an sent out as SMS and sent to the SIM, encrypted with the previous imsi_pseudo_key. <pre> HLR -> SIM NEW PSEUDO IMSI REQ, session_id=1, imsi_pseudo=123, imsi_pseudo_key=(random blob 2) </pre> 3. 5. The SIM applet verifies, that the session_id is higher than the last session_id it has seen (initially: 0). If that is not the case, it discards the message. The SIM applet writes the new pseudo IMSI, IMSI and new pseudo IMSI key and session_id to the SIM card, overwriting the old data. It acknowledges the new data with a SMS back to the HLR, which is encrypted with the *new* imsi_pseudo_key: <pre> HLR <- SIM NEW PSEUDO IMSI RESP ACK, session_id=1, imsi_pseudo=123 </pre> 4. 6. The HLR verifies, that an entry with the session_id and imsi_pseudo from the NEW PSEUDO IMSI RESP ACK message exists in the table. If not, it discards the message. HLR it deletes the old entry with imsi_pseudo=200 from the same IMSI (in the example: the one with imsi_pseudo=200). table. |_. id |_. imsi |_. imsi_pseudo |_. imsi_pseudo_key |_. session_id | | 2 | 100 | 123 | (random blob 2) | 1 | h3. Messages getting lost / messages arriving late h5. What if "NEW PSEUDO IMSI REQ" gets lost? Both In no case, the subscriber is locked out: * the old pseudo IMSI and the new pseudo IMSI entry exist in key continue to work, until we are sure that the HLR. The SIM will use the old pseudo IMSI in the next location update. The HLR will is using them. try to send _the same_ * a new pseudo IMSI with the same new session_id, as soon as the next location update is complete. h5. What if "NEW PSEUDO IMSI RESP" gets lost? Both the old and the new pseudo IMSI entry exist in key will work, even if not ACKed, until: ** we are sure that the HLR. The SIM will use is still using 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. h3. Messages arriving late h5. 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 ACKed, that the message. h5. What if "NEW session of the previous 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. messsages is invalidated h3. Warning the user if SMS don't arrive An attacker could possibly block the SMS with NEW PSEUDO IMSI REQ from arriving at the SIM applet. In that case, the SIM would continue using the old pseudo IMSI indefinitely. We could possibly 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. (Could be possible by listening to EVENT_DOWNLOAD_LOCATION_STATUS?) h3. End2end encryption I need to research more about what can be done in smartcards, but if we could do something like AES with the java smartcards, the approach above should work. h3. Advantages over previous approaches * The range of available IMSIs, and the algorithm for determining IMSIs, can be changed without provisioning new SIM cards * Guaranteed that there are no collisions, since the SIM doesn't need to reproduce the IMSI with a counter value. The HLR determines the IMSI independently and sends it as a whole to the SIM. * SMS arriving late is not an issue CC: @laforge, @neels
