LTrack: Stealthy Tracking of Mobile Phones in LTE(usenix.org)
usenix.org
LTrack: Stealthy Tracking of Mobile Phones in LTE
https://www.usenix.org/conference/usenixsecurity22/presentation/kotuliak
12 comments
Doesn't SS7 allow this too? (if you have the right level of access to any mobile carrier in the world)
Biased opinion (author of PGPP https://www.usenix.org/system/files/sec21-schmitt.pdf). These types of attacks are numerous and easy across multiple generations of cellular. I'd argue the best solution is to simply stop using IMSIs that map directly to a user.
It‘s a very cool approach, I think where it falls short is that each UE will get the same key.
Much of the infrastructure around LTE & 5G is based on the assumption that noone but the operator has this key. However, since everyone has this key, it must now be considered public (since every SIM card can be used decode and encode any connection from any user).
This means that:
- The full connection plaintext will be leaked (yes, you should do TLS, but Metadata) - The IMEI (unique and persistent identifier of a phone) can be requested at will from an attacker (and is often requested by the operator at the beginning), thus allowing you to be tracked not only by the operator, but by any entity sniffing the wireless channel - Measurement Reports containing the exact GPS coordinates can be sniffed or requested by anyone
Still, it could be something for 6G for sure.
Much of the infrastructure around LTE & 5G is based on the assumption that noone but the operator has this key. However, since everyone has this key, it must now be considered public (since every SIM card can be used decode and encode any connection from any user).
This means that:
- The full connection plaintext will be leaked (yes, you should do TLS, but Metadata) - The IMEI (unique and persistent identifier of a phone) can be requested at will from an attacker (and is often requested by the operator at the beginning), thus allowing you to be tracked not only by the operator, but by any entity sniffing the wireless channel - Measurement Reports containing the exact GPS coordinates can be sniffed or requested by anyone
Still, it could be something for 6G for sure.
Out of curiosity are there any providers or products out there offering deterministic, pseudo-randomly generated IMSI's that rollover every e.g. few hours? So the provider would know who you are but anybody else trying to track you in the fashion done in this attack would be hindered.
Think of it like VPN for your cell signal.
Could it be a viable product? (...combined with other features to resist alternative tracking techniques lingering from the privacy-reckless design of the protocols underpinning our mobile infrastructure)
Think of it like VPN for your cell signal.
Could it be a viable product? (...combined with other features to resist alternative tracking techniques lingering from the privacy-reckless design of the protocols underpinning our mobile infrastructure)
That's what the TMSI is supposed to be - (iirc) older cell protocols would send the IMSI over the air all the time, but since at least LTE, possibly earlier, the IMSI is only involved during initial connection to (some region of) the network. During the initial connection, you're assigned a TMSI, which then changes periodically, and you use this for identification on subsequent transmissions.
This is why this paper also talks about determination of IMSI from TMSI.
https://en.wikipedia.org/wiki/Mobility_management#TMSI
But your idea is plausible as an added layer of security - the SIM card could generate a temporary IMSI somehow. I think you'd actually want the next IMSI (or next N IMSIs) to be assigned by the network and communicated to the phone/SIM, rather than deterministically generated. If you deterministically generated the numbers, you'd have to pre-assign each subscriber a pool of numbers that are guaranteed to never overlap with any other subscriber, and this scheme would have to:
This is why this paper also talks about determination of IMSI from TMSI.
https://en.wikipedia.org/wiki/Mobility_management#TMSI
But your idea is plausible as an added layer of security - the SIM card could generate a temporary IMSI somehow. I think you'd actually want the next IMSI (or next N IMSIs) to be assigned by the network and communicated to the phone/SIM, rather than deterministically generated. If you deterministically generated the numbers, you'd have to pre-assign each subscriber a pool of numbers that are guaranteed to never overlap with any other subscriber, and this scheme would have to:
1. assign a large enough pool of IMSIs to each subscriber to handle all future communications with the network
2. make it so it isn't trivial to determine whether two fake IMSIs are the same subscriber (so you can't do something like a fixed prefix + HOTP or something).Something like what the Find My network does (ie. 256 bit public ECDSA keys that are derived from a master key) would probably work.
This is part of the 5g standard.
https://www.techplayon.com/5g-nr-global-unique-temporary-ide...
Some operators do this by the SIM, Sierra Wireless as a virtual operator for example has a smart SIM that doles out IMSIs to the modem to use depending on the roaming and signal parameters. This way they can provide global access without operator roaming - if you go to another country the SIM will give you an IMSI associated with a local subscription.
So I guess you can just use this tech to continuously rotate IMSIs among a large pool every few hours if you'd want.
So I guess you can just use this tech to continuously rotate IMSIs among a large pool every few hours if you'd want.
The IMSI to TMSI process is quite interesting IMO. It embeds the AdaptOver attack, documented here: https://arxiv.org/pdf/2106.05039v1.pdf
From LTrack:
>We propose a new type of IMSI Catcher, named IMSI Extractor. Our IMSI Extractor does not rely on fake base stations but instead uses a combination of low-power surgical message overshadowing and uplink/downlink sniffing. Even if our catcher injects a message, it does so in line with LTE protocol specification, making it hard to detect with existing IMSI Catcher detection techniques. We discuss the techniques that would be needed to detect this attack. We successfully tested our IMSI Extractor on 17 smartphones connecting to an industry-grade eNodeB.
Do they need the keys to the LTE network to perform this attack or is the encryption / protocol vulnerable to attackers without this info?
From LTrack:
>We propose a new type of IMSI Catcher, named IMSI Extractor. Our IMSI Extractor does not rely on fake base stations but instead uses a combination of low-power surgical message overshadowing and uplink/downlink sniffing. Even if our catcher injects a message, it does so in line with LTE protocol specification, making it hard to detect with existing IMSI Catcher detection techniques. We discuss the techniques that would be needed to detect this attack. We successfully tested our IMSI Extractor on 17 smartphones connecting to an industry-grade eNodeB.
Do they need the keys to the LTE network to perform this attack or is the encryption / protocol vulnerable to attackers without this info?
It doesn‘t need any keys, since the protocol itself is vulnerable to this. The Identity Request message that is sent is unauthenticated, but the phone replies with the IMSI nonetheless.
Note that this is just one part of the attack, the attack also includes fully passive localization of phones.
Note that this is just one part of the attack, the attack also includes fully passive localization of phones.
These of attacks do not works against 5G, from the Countermeasures (Section 8), "In 5G, IMSI catching is no longer possible since IMSI is encrypted using the network’s public key. Thus, the attacker cannot decode the IMSI."
They still do, since in 5G you can capture a SUCI, replace it on a later connection attempt, and observe if the phone can still attach. See [1], section 5.2.3, and it‘s implemented in [2].
Finally, localization attacks could potentially still work as well.
[1] https://arxiv.org/pdf/1806.10360.pdf [2] https://dl.acm.org/doi/10.1145/3448300.3467826
Finally, localization attacks could potentially still work as well.
[1] https://arxiv.org/pdf/1806.10360.pdf [2] https://dl.acm.org/doi/10.1145/3448300.3467826