By decoupling the user identity from a permanent, globally unique IMSI, we make IMSI catcher / Stingray attacks less "useful" as the IMSI is changing and isn't tied to the user. They can attack your IMSI, but it won't be tied to you and it is ephemeral.

Yes. With a traditional VPN you are trusting that VPN provider with all of your traffic. They know your identity and everything you do. The two hop architecture we use decouples that information such that neither hop has both the user's identity and their usage information. In our case, the second hop is Fastly.

Yes, that’s true. But let’s say I trust my VPN provider and do not trust my cell service provider. Does PGPP add value for me in that case?

As with all mobile service it really depends on coverage in your area. The baseline service is LTE.

This was a research project that we undertook while at our respective universities. We decided to spin it out as we think it's useful. We are not funded by the government or Princeton (while Princeton owns the IP).

Absolutely, we're working on this currently.

I would definitely give it a try if google play services are not required.

IMEIs are definitely a challenge, but they're also different from these other identifiers because the IMEI is not a network identifier. When you attach to a mobile network, the attach process uses the IMSI to authenticate you and then the assigned IP address to provide data connectivity. The IMEI doesn't figure into it. In addition, an IMEI isn't part of an account or bound inherently to a user identity from the network's perspective. Technically the IMEI isn't required for the network to function.

That being said, IMEIs are yet another identifier among many that could be used for tracking in the future. We've been working on ways to prevent this from happening while still allowing some common uses such as the stolen phone database that IMEIs are supposed to be used for to continue to work, but in a privacy-preserving manner. (Rolling this out will require cooperation from several large players, likely including Apple, Google, and mobile operators, so it's not an easy road.)

Hey, I dream of a service like this and want you to succeed! But:

> Technically the IMEI isn't required for the network to function.

This is not correct.

Every carrier's SIM card firmware collects and reports the IMEI and modem manufacturer and firmware revision after AKA but before allowing any meaningful use of their network. There's nothing sinister about this; they have to do it in order to be aware of malfunctioning chipsets that crap all over their valuable spectrum. They most definitely do this on the first attach for a new IMSI, so they can block known-badly-behaving modems and update their IMSI<->IMEI mapping table. Verizon outright blocks the Quectel EC25 in many areas.

The only practical difference with IMEIs is that they are never sent in the clear. IMSIs are sent in the clear on the first network attach, which is the loophole that stingrays exploit. But most of your potential customers are more worried about carrier tracking than stingrays.

Have you found any carrier that will let you use random IMEIs, taking a different one each day like the IMSI? I haven't. Quectel hardware and a few Sierra devices will let you change the IMEI, so you can do the experiment. Osmocom has tools for sniffing the transactions between the SIM card and the baseband, although with an eSIM that may require some tricky desoldering work. Maybe you can solder an eSIM chip to a SIMcard-shaped PCB.

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.

The regular attach procedure is unchanged. In the simplest version we give every SIM the identical IMSI and key.

However, their use is to only gain IP connectivity - the equivalent of an allow list on the backend db (AUSF) which gives you IP connectivity. At that point you do billing and auth at the PGPP-GW using oblivious auth tokens.

Thanks! You mention that this is the simplest version, is there one where you use distinct keys?

Also, regarding the IMEI - let‘s assume the UE nullified it, how would you distinguish between a legitimately nullified UE and a stolen UE that had its IMEI nullified?

Yes, in a perfect world, they would simply choose to not track. We (I'm a co-author on the research) chose to change things such that we don't need to rely on carrier benevolence.

Our fix changes the architecture to nullify an identity that has long been used to track users. The data has simply been available for them to sell as a byproduct of running a network.