Ackhually, it is that hard, unless your method relies on millions of your devices out in the wild acting as sensors in a mesh network, as Apple does.
There are very straightforward solutions, depending on the threat model. For example, the app could send VW a private key every day, and VW would send that key to the car. Then the car sends periodic location reports, encrypted to that key. VW can, upon request, send the report to the app, which decrypts it. But VW can’t decrypt the report itself, so they don’t know the location of the car. Also, it’s forward secure in the sense that a leak of VW’s database is entirely useless after a day.
Otherwise, if there is no pre-existing private channel, the key (which by the way would have to be the public key, not the private key) could be switched out by VW acting as a man-in-the-middle, allowing it to access all encrypted content going through it.
The same is true for Apple. There are parts of the protocol or the pairing where you have to trust Apple, either their servers, or if the establishment happens locally via bluetooth or similar, their software that runs on the local devices.
It would also introduce a lot of additional failure modes.
Doable but not exactly trivial.
I realize that modern development has layers and layers of documents and teams and overcomplicated interfaces, but this is the kind of thing that could be done by one developer, using two servers and a load balancer (or a more creative HA scheme with client assistance that can easily survive complete loss of a datacenter or two), that can handle the entire fleet.
My car for example doesn't have reliable connection when it's parked in the garage, which is where I charge it.
Your solution would add a lot of extra edge cases that needs to be considered.
You have to ensure the updated key is reliably transferred to the mothership in a timely fashion, and subsequently that the key is reliably transferred to the car in a timely fashion.
That's the back-end stuff. There's also the front-end stuff, like will my SO understand why her app isn't showing the car's location but mine is?
Not saying it's impossible, but it adds a lot of complexity beyond simply encrypting the location with multiple keys.
Losing connection for extended periods of time can get in the way of "timely" key updates but they won't cause the encryption to fail.
> That's the back-end stuff. There's also the front-end stuff, like will my SO understand why her app isn't showing the car's location but mine is?
Well the reasons I can think of are either things like the server being broken, which can happen without any encryption, or she didn't finish setting up her app and waiting for it to sync which can also happen without encryption. Or she was removed from the list because she didn't open the app for a year... which can also happen without encryption.
To be fair, if the car is offline while a newly installed app logs in, then the app won’t be able to locate the car until the car checks in. Which is not actually the end of the world, and there are ways to mitigate this. (See iMessage and Keybase for a couple of different approaches to this. See Signal for a shockingly poor group of bizarrely mutually incompatible solutions that barely work. I think that Matrix tries, too. MLS should be able to handle it, and piggybacking off an existing standard like MLS might be entirely reasonable albeit dramatically more complex than the simple solution I outlined.)
Where do you work and are you hiring?