A simple software fix could limit location data sharing(arstechnica.com)
arstechnica.com
A simple software fix could limit location data sharing
https://arstechnica.com/information-technology/2021/08/a-simple-software-fix-could-limit-location-data-sharing/
17 comments
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?
I wonder what incentives to do so might look like?
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.
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.
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.
I'm co-author of this research (with my colleague Paul) -- happy to answer any questions.
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?
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?
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).
The "fix" is carriers simply choosing not to track you, which they could always do but don't want to.
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.
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.
Can either of you recommend resources or tools for learning how to design good protocols?
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.
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!
Can you elaborate a bit on that? Is every USIM using the same shared key?
Thanks!
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.
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?
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?
Additional question for my understanding - this needs an app running in the background to send the signed token at every other time interval, correct?
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).
BTW, why does truecaller on android 10 show an overlay after a call when settings page specifically disables it ?