Show HN: PGPP (Pretty Good Phone Privacy) – a new type of mobile privacy service(play.google.com)
play.google.com
Show HN: PGPP (Pretty Good Phone Privacy) – a new type of mobile privacy service
https://play.google.com/store/apps/details?id=com.invisv.pgpp&hl=en_US&gl=US
13 comments
> We provide service using eSIMs (so you need an eSIM capable Android for this part). So we don't learn which eSIM your phone gets each time (your IMSI now changes periodically), we authenticate you with a cryptographic protocol (Chaum's blind signatures) that proves you should get a new eSIM but doesn't reveal your identity.
The eSIM provisioning protocol (which you cannot change; it's hardware/firmware) sends you (the provisioning provider) the eSIM's permanent ID (the EID) once it has negotiated an encrypted channel with you.
https://en.wikipedia.org/wiki/ESIM#Usage
You should post technical details on what you're doing with the eSIMs. Everything I've read about them indicates that what you're claiming isn't possible. It's a system designed by the carriers, with typical carrier priorities embedded in it.
The eSIM provisioning protocol (which you cannot change; it's hardware/firmware) sends you (the provisioning provider) the eSIM's permanent ID (the EID) once it has negotiated an encrypted channel with you.
https://en.wikipedia.org/wiki/ESIM#Usage
You should post technical details on what you're doing with the eSIMs. Everything I've read about them indicates that what you're claiming isn't possible. It's a system designed by the carriers, with typical carrier priorities embedded in it.
> Relay does not allow UDP traffic (applications that attempt to use UDP will find their traffic blocked on the device itself). Eventually it will allow UDP traffic to certain destination port numbers, such as 443.
This is a very weird restriction that I've never seen before. Can you explain where it emanates from? I can only assume that this is motivated by logging.
Do you reject ICMP as well?
What happens if I tunnel UDP inside of headers that make the packet look like a TCP SYN+ACK packet? This would be IPv6 to avoid CGNAT of course.
PS, your blog is missing the RSS/ATOM feed.
This is a very weird restriction that I've never seen before. Can you explain where it emanates from? I can only assume that this is motivated by logging.
Do you reject ICMP as well?
What happens if I tunnel UDP inside of headers that make the packet look like a TCP SYN+ACK packet? This would be IPv6 to avoid CGNAT of course.
PS, your blog is missing the RSS/ATOM feed.
Oh, perhaps we should have gone into it in more detail, but this is a direct consequence of the architecture of IETF MASQUE. It's not a VPN tunnel of the classic sort. Instead it's nested HTTPS-based proxying of E2EE TLS streams. The reason UDP is a risk to Fastly in that context is that their infrastructure can be instructed in connection requests to create non-congestion-controlled streams to arbitrary destinations, and they have a lot of bandwidth at their disposal. We want to put mitigations in place to prevent use of this infrastructure for DoS attacks before opening up UDP widely.
You're providing network access. Layer 3. IP. HTTP(S) is at layer 5; has nothing to do with your service.
Nor does Fastly. Serious, WTF does a CDN have to do with being an ISP?
> they have a lot of bandwidth at their disposal.
You think Level3/Lumen/Centurylink and Verizon don't? They certainly allow UDP.
Besides, who are you going to DOS using a cellular uplink?
Nor does Fastly. Serious, WTF does a CDN have to do with being an ISP?
> they have a lot of bandwidth at their disposal.
You think Level3/Lumen/Centurylink and Verizon don't? They certainly allow UDP.
Besides, who are you going to DOS using a cellular uplink?
Very nice! Not sure this would fly here in Europe though: operators are obligated to verify your identity (passport/Id card required) before assigning an (e)SIM to your contract.
So in order to assign eSIM you qualify as a VMNO?
So in order to assign eSIM you qualify as a VMNO?
Thanks for the comment -- the regulations in Europe for this vary from country to country. So for the mobile piece of this (the pro/core plans), we limit signups to countries where such requirements don't exist. However, roaming after subscription is allowed.
PGPP Relay service, on the other hand, is available for use anywhere.
Also, we only provide eSIM based mobile data service, so we aren't technically an MVNO.
PGPP Relay service, on the other hand, is available for use anywhere.
Also, we only provide eSIM based mobile data service, so we aren't technically an MVNO.
Is there any plan to release via apk or alternative installs for those with GrapheneOS, CalyxOS, CopperheadOS, etc.
Absolutely, we're working on this currently.
I would definitely give it a try if google play services are not required.
Can cellular base stations still track your location via your device's IMEI?
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.)
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.
> 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.
This is awesome. Thank you for the great work!!!!!
A couple years ago we had the idea that we could decouple your identity from your SIM (IMSI), so the mobile operator wouldn't know who you are but still provides you service. We did research, figured it out, and published it last year at Usenix Security. Then we took it to every mobile operator we could to see if they'd do it, but mostly got shrugs, confusion, or hostility. (We still hold out hope they'll change their minds.) So we decided we had to build and deploy it ourselves. And the mobile network is just the first part -- we also provide decoupled IP privacy (Relay) in PGPP via a partnership with Fastly, for when you're on WiFi or mobile data.
The implementation is simple: for mobile privacy we decouple authentication from connectivity. Those are conflated today. We provide service using eSIMs (so you need an eSIM capable Android for this part). So we don't learn which eSIM your phone gets each time (your IMSI now changes periodically), we authenticate you with a cryptographic protocol (Chaum's blind signatures) that proves you should get a new eSIM but doesn't reveal your identity. Then you get mobile data service. This isn't something that exists today, despite the tracking/data collection that's happened both by third parties (SDRs / IMSI catchers) and operators themselves. It's like MAC randomization for mobile networks.
We figured users would like better IP privacy too, so we used IETF MASQUE and collaborated with Fastly to provide relay service in PGPP as well. Relay service works on almost any Android device. This uses TLS to tunnel your traffic (which itself will usually be TLS encrypted, for almost all Web traffic today) through two hops and then to the rest of the Internet. The first hop is us -- we hide your IP but learn nothing of your traffic or where it's headed. The second hop is Fastly, who then connects you to the IP of the server you're trying to reach, but all they see is an INVISV IP trying to connect to some other IP. The site you're connecting to terminates your TLS stream but just sees it coming from Fastly.
This is a beta and there are several things that aren't ideal. We don't have free plans because providing actual connectivity is pretty expensive. We know that data-only mobile service isn't for everyone (that's what our mobile plans provide -- no phone number). So we offer Relay service on its own for folks who want that. We also know eSIMs are not ideal either, so we'd like to generalize that down the road.
We're focused on privacy, not just on mobile, and we'd love your feedback on the service and ideas about this and where to go next.
Thanks!
Barath and Paul