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.
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).
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.)
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.
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.
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.