It isn't solved for computer networks, this is exactly the same as the current debate about secure boot. Secure boot is an open standard, but we've not agreed about who can hold the keys: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot
Here, the EU has effectively said that someone with physical access to the car can generate their own keys (since anyone can pretend to be a mechanic, and all mechanics are allowed to generate keys), and the car manufacturers are saying that they should have the root keys, so that only approved dealers can create new ones. Much like Microsoft saying to ARM tablet manufacturers that they have to allow only Microsoft's keys in ARM tablets, blocking end users from installing their self-signed OS.
tl;dr: the problem is not protocols, it is key management.
It isn't solved for computer networks, this is exactly the same as the current debate about secure boot.
I would disagree. To me this sounds like a perfect scenario for asymmetric encryption, which would solve this in a secure fashion.
Obviously someone should have a secure repository for official keys issued, so that duplicates can be made, upon request, upon owners' authorization. It might be bothersome and cumbersome, but the point is it should be a possible process, even for third party mechanical shops.
And for me the car-manufacturer sounds like a natural holder of this repo.
On the other hand, if you have access to the car and the key, it should be open enough to allow you to (re-)program it with your own keys if you like.
As far as I can see, that should satisfy everyone involved, while maintaining a secure architecture.
this sounds like a perfect scenario for asymmetric encryption
I suspect that they are already using asymmetric encryption, with some sort of mechanism to allow third party mechanics (and thieves pretending to be mechanics) to sign new fobs.
the point is it should be a possible process, even for third party mechanical shops.
Yes, agreed. The issue seems to be how much faith you put in the manufacturers to play ball. If they have to incur a cost to manage keys, that might lead to legislation around putting limits on the amount they can charge for access. It seems like a rabbit hole full of problems to leave them in charge. What happens when someone who has lost the keys to their second hand car goes to a third party mechanic to unlock the computer in their car built by a manufacturer who has gone out of business?
it should be open enough to allow you to (re-)program it with your own keys
With this strategy, the solution the the above question is to hope that the user added their own key/certificate to the car in advance. I suspect that the people who would do that would intersect strongly with those who are meticulous with keeping a spare key in a secure place anyway, so it would only help a minority of people.
Some of the other ideas, like time locks or falling back to a physical key to create new fobs, sound like they may do a better job of ensuring user freedom. Those solutions might apply to secure boot too, but it still seems unsolved in practice.
There is a difference, which is that a car is a physical thing.
Imagine that we had the current process. Except that every time a key gets reprogrammed, a record was made of which mechanic's key was used, and we have a mechanism to revoke particular issued keys.
This will not stop my car from being stolen. But we can identify which mechanic's key was used to do it, and I'm able to brick that car remotely.
You've just increased the cost of stealing a car this way, and reduced the cost of having it stolen. That may well be enough to convince thieves to move on to an easier type of target.
Here, the EU has effectively said that someone with physical access to the car can generate their own keys (since anyone can pretend to be a mechanic, and all mechanics are allowed to generate keys), and the car manufacturers are saying that they should have the root keys, so that only approved dealers can create new ones. Much like Microsoft saying to ARM tablet manufacturers that they have to allow only Microsoft's keys in ARM tablets, blocking end users from installing their self-signed OS.
tl;dr: the problem is not protocols, it is key management.