Comment by awelkie
8 years ago
Calls could be done over IP, and as long as you could anonymously authenticate to the tower then you could be granted a new IP address at each tower via something like DHCP. I imagine roaming and handovers would have to be done on the end-device though; the end-device would need to proactively associate to new towers and both ends of the voice call would need to agree to switch to the new IP address.
But if the tower operators collude then they can still track you across towers by localizing the physical source of the end-device's signal.
If you really wanted to do this, a more secure approach is onion routing. It's essentially the same problem -- attempting to preserve anonymity in the face of adversarial network hardware, while being limited by a requirement to enter / exit through certain nodes.
So you'd want a mesh network, formed adhoc out of currently in range cellular device neighbors, with packets re-encapsulated and encrypted at each hop, eventually hitting the tower from a random device.
Authorization would be impossible (the intent of the scheme) without a side channel (as you can't simultaneously have individual authorization and individual anonymization). Which makes it a non-starter for commercial use.
Oh yeah, that's an interesting solution.
I'm not sure simultaneous authorization and anonymization is impossible. Couldn't you use something like Chaum's e-cash to obtain tokens that guarantee the holder the right to use the network for some amount of data, but these tokens are tradeable and therefore the spender doesn't have to be the same as the buyer. Then you could spend this token in the network to get access and the network could authenticate the token without identifying the spender. I'm guessing something like zcash could be used as well...
That's what I meant by side channel. So yes, you can split authorization responsibilities into a different entity, but then that entity is going to be able to deanonymize you.
And it wouldn't play well with billing accounts being deactivated / reactivated.
And... now that I think about it, given the tower:location mapping, you'd also have to include bouncing traffic back out to a non-tower-sharing peer and then back into their tower w/ randomized timing, else outer layers of encapsulation would still identify tower association.
Which means latency would be utter crap.
Anonymous attestation protocols is a thing
"without a side channel"
Do you have any links where this is done without a third party?
1 reply →
Proving to the tower that you are a paying user should be easy, but routing the data securely will not be as easy. You'd probably need some kind of onion routing or similar on the back haul, unless you want to forego incoming calls. I would not like to have to forego those. Also, why even bother with DHCP, just say that the tower assigns you an IP, without knowing your MAC, right after you were able to prove that you are a paying customer. Handling data quota is going to be non-trivial there, as you'd either need to route everything to the provider anyway, or have a DoS-proof way of decreasing your remaining quota, e.g. by signing a new value with some key of yours, ensuring that the tower can't use that as your ID (maybe don't tell him or so), and then have to prove to the tower that your quota really got diminished, preferably without revealing how much is remaining, and just telling the tower that you still got something to spare. The main issue seems to be that you'd have to hold a session with each tower where you got quote allocated, as you can't re-run that quote proof for each packet. The finest granularity that seems remotely reasonable would be like 16kiB of traffic, which you would deduct form your account, let it get claimed by the tower, and then be required to repeat for each successive block (obviously you could assign larger blocks, but a block, once assigned, can't be put back without serious unnecessary cryptographic hurdles.
I am not well-versed enough in these cryptographic details to tell you how one could do this exactly, but I doubt it's impossible/infeasible to create a cellular protocol technically as powerful as LTE, but without tracking ability by the tower or the provider (byzantine fault tolerance, stochastic).