5 ms·

A simple software fix could limit location data sharing

10 points by jaytaylor 5y ago

nobody9999 5y ago
It seems like a good idea. But carriers have no incentive to limit the data they collect. I wonder what incentives to do so might look like?
- Nextgrid 5y ago
  Better GDPR enforcement would be an incentive. The GDPR introduces the principle of data minimisation which means that you must collect the least amount of data possible to deliver a particular service (unless the user consents to sharing more which should be opt-in, you can’t force them or use dark patterns to make them opt-in). But considering even basic violations that are trivial to rectify such as the Facebook SDK or Google Analytics being everywhere are not punished, there is no chance they’d go after cell carriers.
- barathr 5y ago
  You're right: the big carriers don't have much incentive to deploy this -- yet. We think deployment will come through three paths: 1) virtual operators (MVNOs) can differentiate themselves by offering PGPP-based privacy-enhanced service, 2) big carriers (MNOs) will want to (eventually) claim that they are doing the right thing on privacy and jump on board, and 3) new regulations (in various U.S. states and post-GDPR rules that are being drafted) are stipulating that location data is private so it's better to not have it rather than have to prove that it's being handled properly.
barathr 5y ago
I'm co-author of this research (with my colleague Paul) -- happy to answer any questions.
- NotSwift 5y ago
  First of all, congratulations, when you get Bruce Schneier to endorse your work, you have probably done something interesting. But still the article is not very clear on technical details. Of course on initial contacts your phone has to provide information about your service provider (they will somehow have to pay for your communications) and it has also has to have some form of identification about your phone (so that the service provider can decide if they want to pay for it). If I understand it correctly, normally this identification is the IMSI, which is normally constant for your phone. From the article it is not clear if you are proposing to generate multiple IMSI's for a phone or using other types of information in the protocols. Do you have some links to a more technical explanation of PGPP?
  - neolog 5y ago
    https://www.usenix.org/system/files/sec21-schmitt.pdf https://www.usenix.org/system/files/sec21-schmitt.pdf
  - barathr 5y ago
    Thanks! So the paper that the other commenter linked is a good deep dive. The basic answer to your question is that we have multiple variants but the simplest is that phones using PGPP would have the same IMSI; once you do that, you hide who's who but create a new problem of how to make sure users are valid paying subscribers. We solve that new problem by developing a new oblivious authentication protocol that can verify someone is a valid user (i.e. someone who has authentication tokens that are not linked to them but are issued by the network).
lupire 5y ago
The "fix" is carriers simply choosing not to track you, which they could always do but don't want to.
- prschmitt 5y ago
  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.
neolog 5y ago
Can either of you recommend resources or tools for learning how to design good protocols?
- barathr 5y ago
  If you're interested in security protocols, I'd recommend Bruce Schneier's book Cryptography Engineering (and Ross Anderson's Security Engineering). If general networking protocols, there are many options -- Kurose, Peterson and Davie, Tanenbaum, etc.
red0point 5y ago
I skimmed through the paper, what isn’t clear to me is how the original Registration Procedure is modified exactly. How is the Authentication Procedure done by the AUF when it doesn’t know the shared key K between the USIM and the network? Can you elaborate a bit on that? Is every USIM using the same shared key? Thanks!
- red0point 5y ago
  Additional question for my understanding - this needs an app running in the background to send the signed token at every other time interval, correct?
  - barathr 5y ago
    That's right. (The token is used for oblivious authentication, so it's not identifying.) The attach procedure works as usual, it's just that the IMSI/SUPI is no longer individually identifying (which then necessitates the oblivious authentication protocol).
- prschmitt 5y ago
  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.
  - red0point 5y ago
    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?
2Gkashmiri 5y ago
Why doesn't android have an os level permission manager, so if I decide to not give location to maps, the os would simply say no signal and continue to work. Same for sms access or contacts or phone. I saw one ROM do this, realme it was I think but apps apparently see this and they complain so no point. BTW, why does truecaller on android 10 show an overlay after a call when settings page specifically disables it ?

10 points by jaytaylor 5y ago

It seems like a good idea. But carriers have no incentive to limit the data they collect. I wonder what incentives to do so might look like?

Nextgrid 5y ago
Better GDPR enforcement would be an incentive. The GDPR introduces the principle of data minimisation which means that you must collect the least amount of data possible to deliver a particular service (unless the user consents to sharing more which should be opt-in, you can’t force them or use dark patterns to make them opt-in). But considering even basic violations that are trivial to rectify such as the Facebook SDK or Google Analytics being everywhere are not punished, there is no chance they’d go after cell carriers.
barathr 5y ago
You're right: the big carriers don't have much incentive to deploy this -- yet. We think deployment will come through three paths: 1) virtual operators (MVNOs) can differentiate themselves by offering PGPP-based privacy-enhanced service, 2) big carriers (MNOs) will want to (eventually) claim that they are doing the right thing on privacy and jump on board, and 3) new regulations (in various U.S. states and post-GDPR rules that are being drafted) are stipulating that location data is private so it's better to not have it rather than have to prove that it's being handled properly.

barathr 5y ago

I'm co-author of this research (with my colleague Paul) -- happy to answer any questions.

NotSwift 5y ago
First of all, congratulations, when you get Bruce Schneier to endorse your work, you have probably done something interesting. But still the article is not very clear on technical details. Of course on initial contacts your phone has to provide information about your service provider (they will somehow have to pay for your communications) and it has also has to have some form of identification about your phone (so that the service provider can decide if they want to pay for it). If I understand it correctly, normally this identification is the IMSI, which is normally constant for your phone. From the article it is not clear if you are proposing to generate multiple IMSI's for a phone or using other types of information in the protocols. Do you have some links to a more technical explanation of PGPP?
- neolog 5y ago
  https://www.usenix.org/system/files/sec21-schmitt.pdf https://www.usenix.org/system/files/sec21-schmitt.pdf
- barathr 5y ago
  Thanks! So the paper that the other commenter linked is a good deep dive. The basic answer to your question is that we have multiple variants but the simplest is that phones using PGPP would have the same IMSI; once you do that, you hide who's who but create a new problem of how to make sure users are valid paying subscribers. We solve that new problem by developing a new oblivious authentication protocol that can verify someone is a valid user (i.e. someone who has authentication tokens that are not linked to them but are issued by the network).

lupire 5y ago

The "fix" is carriers simply choosing not to track you, which they could always do but don't want to.

prschmitt 5y ago
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.

neolog 5y ago

Can either of you recommend resources or tools for learning how to design good protocols?

barathr 5y ago
If you're interested in security protocols, I'd recommend Bruce Schneier's book Cryptography Engineering (and Ross Anderson's Security Engineering). If general networking protocols, there are many options -- Kurose, Peterson and Davie, Tanenbaum, etc.

red0point 5y ago

I skimmed through the paper, what isn’t clear to me is how the original Registration Procedure is modified exactly. How is the Authentication Procedure done by the AUF when it doesn’t know the shared key K between the USIM and the network? Can you elaborate a bit on that? Is every USIM using the same shared key? Thanks!

red0point 5y ago
Additional question for my understanding - this needs an app running in the background to send the signed token at every other time interval, correct?
- barathr 5y ago
  That's right. (The token is used for oblivious authentication, so it's not identifying.) The attach procedure works as usual, it's just that the IMSI/SUPI is no longer individually identifying (which then necessitates the oblivious authentication protocol).
prschmitt 5y ago
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.
- red0point 5y ago
  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?

2Gkashmiri 5y ago

Why doesn't android have an os level permission manager, so if I decide to not give location to maps, the os would simply say no signal and continue to work. Same for sms access or contacts or phone. I saw one ROM do this, realme it was I think but apps apparently see this and they complain so no point. BTW, why does truecaller on android 10 show an overlay after a call when settings page specifically disables it ?