Hello All
I wanted to ask your about something regarding user privacy leakage in the broadcast channels. As i have been sniffing and testing myself and i found that on the paging requests type 1 IMSI along with TMSI is sent.
I have came to understand that first sending two identifications is the norm, but what i dont understand the high rate of sending IMSI as mobile identification, and as per specification its noted that either TMSI OR IMSI are sent, so does that by any mean could be a configuration issues from the MSC/VLR side that should be changed, is this the norm? if its the norm, then why using TMSI.
From your experience what are the countermeasures you think that should be
taken from the operator side to protect against such information leaks, or there is nothing that an operator can do much for this ?What could be the different cases where the IMSI could be sent ?
Thanks
Hi Loay,
On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
I wanted to ask your about something regarding user privacy leakage in the broadcast channels. As i have been sniffing and testing myself and i found that on the paging requests type 1 IMSI along with TMSI is sent.
Please note that those two identities in one paging request message have no relation to each other. There are simply Paging message types that allow combination of multiple (I think up to 4x TMSI), for example.
So the important observation is that IMSIs are present in PCH messages at all, and not that they're alongside TMSI.
I have came to understand that first sending two identifications is the norm,
a paging request can contain 1..4 identities. See above.
but what i dont understand the high rate of sending IMSI as mobile identification, and as per specification its noted that either TMSI OR IMSI are sent, so does that by any mean could be a configuration issues from the MSC/VLR side that should be changed, is this the norm? if its the norm, then why using TMSI.
We have limited insight into what kind of equipment operators use at the MSC/VLR, and why that equipment behaves in certain ways.
In general, paging by IMSI _can_ be an indication that the VLR has a fixed number of IMSI/TMSI mappings that it can store, and that this fixed limit is overflowing, causing the VLR to "forget" older mappings. This in turn forces the network to page by IMSI. Such limitations could actually be limitations of physical resources (memory), but they could also very well be licensing related (you might pay for the number of concurrent subscriber records).
From your experience what are the countermeasures you think that should be taken from the operator side to protect against such information leaks, or there is nothing that an operator can do much for this ?What could be the different cases where the IMSI could be sent ?
I don't think there's anything more specific than: * look at your paging channel * check for ratio of IMSI vs. TMSI pages * ensure your VLR doesn't overflow * keep debugging if you can find a valid reason for this. If not, work with your VLR supplier to discover what's wrong.
Hi Harald
Yes yes I totally understand , so what could be the cases for sending the IMSI and what would be the possible remediation for such thing
On Sunday, 20 May 2018, Harald Welte laforge@gnumonks.org wrote:
Hi Loay,
On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
I wanted to ask your about something regarding user privacy leakage in
the
broadcast channels. As i have been sniffing and testing myself and i
found
that on the paging requests type 1 IMSI along with TMSI is sent.
Please note that those two identities in one paging request message have no relation to each other. There are simply Paging message types that allow combination of multiple (I think up to 4x TMSI), for example.
So the important observation is that IMSIs are present in PCH messages at all, and not that they're alongside TMSI.
I have came to understand that first sending two identifications is the norm,
a paging request can contain 1..4 identities. See above.
but what i dont understand the high rate of sending IMSI as mobile identification, and as per specification its noted that either TMSI OR
IMSI
are sent, so does that by any mean could be a configuration issues from the MSC/VLR side that should be changed, is this the norm? if its the
norm,
then why using TMSI.
We have limited insight into what kind of equipment operators use at the MSC/VLR, and why that equipment behaves in certain ways.
In general, paging by IMSI _can_ be an indication that the VLR has a fixed number of IMSI/TMSI mappings that it can store, and that this fixed limit is overflowing, causing the VLR to "forget" older mappings. This in turn forces the network to page by IMSI. Such limitations could actually be limitations of physical resources (memory), but they could also very well be licensing related (you might pay for the number of concurrent subscriber records).
From your experience what are the countermeasures you think that should
be
taken from the operator side to protect against such information leaks,
or
there is nothing that an operator can do much for this ?What could be the different cases where the IMSI could be sent ?
I don't think there's anything more specific than:
- look at your paging channel
- check for ratio of IMSI vs. TMSI pages
- ensure your VLR doesn't overflow
- keep debugging if you can find a valid reason for this. If not, work with your VLR supplier to discover what's wrong.
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Sun, May 20, 2018 at 05:14:41AM -0400, loay abdelrazek wrote:
Hi Harald
Yes yes I totally understand , so what could be the cases for sending the IMSI and what would be the possible remediation for such thing
It sounds like you actually don't "totally" understand and are asking for a 101 on IMSI and TMSI?
The subscriber is identified to the network by its IMSI, which stays constant.
A new TMSI is given on every Location Update, meaning it changes all the time, which is good for privacy. The network does its best to remember the last TMSI the phone has been given.
But before the network can know who that subscriber is, things have to start out with the IMSI. That's normally when the phone asks for a Location Update for the first time. Usually the new TMSI is sent to the phone ciphered, so that the IMSI <-> TMSI mapping is essentially secret.
A TMSI is short-lived and an MSC may decide not to store IMSI<->TMSI mappings forever, for various/unknown reasons. So as soon as there is no TMSI left in the MSC's subscriber state, the only way to page is by IMSI.
Also, the phone may have forgotten its TMSI, e.g. after roaming to a different network.
But: AFAICT, under "proper" operations, a subscriber should have a TMSI after a Location Update, and either detach when it leaves or be implicitly detached by timeout. So as long as it is Page-able by the MSC, it should have a TMSI as well. In other words, the MSC should either have a TMSI to page for, or the subscriber's state should be "not attached", i.e. can't page anyway. Bottom line, whenever paging goes out by IMSI, the MSC has actively decided to not bother about privacy (by implementation, config or by licensing details).
IIRC, the only way to get an IMSI paging out of osmo-msc is to globally switch off TMSI allocation.
~N
Thanks Neels, that was informative
On Tuesday, 22 May 2018, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
On Sun, May 20, 2018 at 05:14:41AM -0400, loay abdelrazek wrote:
Hi Harald
Yes yes I totally understand , so what could be the cases for sending the IMSI and what would be the possible remediation for such thing
It sounds like you actually don't "totally" understand and are asking for a 101 on IMSI and TMSI?
The subscriber is identified to the network by its IMSI, which stays constant.
A new TMSI is given on every Location Update, meaning it changes all the time, which is good for privacy. The network does its best to remember the last TMSI the phone has been given.
But before the network can know who that subscriber is, things have to start out with the IMSI. That's normally when the phone asks for a Location Update for the first time. Usually the new TMSI is sent to the phone ciphered, so that the IMSI <-> TMSI mapping is essentially secret.
A TMSI is short-lived and an MSC may decide not to store IMSI<->TMSI mappings forever, for various/unknown reasons. So as soon as there is no TMSI left in the MSC's subscriber state, the only way to page is by IMSI.
Also, the phone may have forgotten its TMSI, e.g. after roaming to a different network.
But: AFAICT, under "proper" operations, a subscriber should have a TMSI after a Location Update, and either detach when it leaves or be implicitly detached by timeout. So as long as it is Page-able by the MSC, it should have a TMSI as well. In other words, the MSC should either have a TMSI to page for, or the subscriber's state should be "not attached", i.e. can't page anyway. Bottom line, whenever paging goes out by IMSI, the MSC has actively decided to not bother about privacy (by implementation, config or by licensing details).
IIRC, the only way to get an IMSI paging out of osmo-msc is to globally switch off TMSI allocation.
~N
Thanks Harald, my bad I didn’t go through your reply throughly
Much appreciated
On Sunday, 20 May 2018, Harald Welte laforge@gnumonks.org wrote:
Hi Loay,
On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
I wanted to ask your about something regarding user privacy leakage in
the
broadcast channels. As i have been sniffing and testing myself and i
found
that on the paging requests type 1 IMSI along with TMSI is sent.
Please note that those two identities in one paging request message have no relation to each other. There are simply Paging message types that allow combination of multiple (I think up to 4x TMSI), for example.
So the important observation is that IMSIs are present in PCH messages at all, and not that they're alongside TMSI.
I have came to understand that first sending two identifications is the norm,
a paging request can contain 1..4 identities. See above.
but what i dont understand the high rate of sending IMSI as mobile identification, and as per specification its noted that either TMSI OR
IMSI
are sent, so does that by any mean could be a configuration issues from the MSC/VLR side that should be changed, is this the norm? if its the
norm,
then why using TMSI.
We have limited insight into what kind of equipment operators use at the MSC/VLR, and why that equipment behaves in certain ways.
In general, paging by IMSI _can_ be an indication that the VLR has a fixed number of IMSI/TMSI mappings that it can store, and that this fixed limit is overflowing, causing the VLR to "forget" older mappings. This in turn forces the network to page by IMSI. Such limitations could actually be limitations of physical resources (memory), but they could also very well be licensing related (you might pay for the number of concurrent subscriber records).
From your experience what are the countermeasures you think that should
be
taken from the operator side to protect against such information leaks,
or
there is nothing that an operator can do much for this ?What could be the different cases where the IMSI could be sent ?
I don't think there's anything more specific than:
- look at your paging channel
- check for ratio of IMSI vs. TMSI pages
- ensure your VLR doesn't overflow
- keep debugging if you can find a valid reason for this. If not, work with your VLR supplier to discover what's wrong.
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
loay abdelrazek -
Neels Hofmeyr