The obvious but security-oblivious way to do this is to just connect the entertainment system that has the internet connection to one of the car's microcontroller busses. Even if it just needs to send a single command, it's easier than adding another pin and another wire to the appropriate microcontroller on the other end. The problem is that everything on these busses is completely trusted, and there's no authentication. The window motor can't tell whether the signal to roll down the window came from a switch or from the entertainment system.
The simple solution is just to have a separate wire for everything, and source devices that aren't supposed to control destination devices don't get those wires connected. The problem is that the automakers went to microcontroller busses because this creates a rats nest of wires.
The level 2 solution is have some sort of low-level filtering on the commands that are going out from a controller on the bus, so any command that the entertainment system sends to turn off the transmission doesn't make it onto the bus.
The level 3 solution is to have some sort of cryptographic authentication of entities on the bus, so that the endpoint can decide what commands it's going to accept from what source.
As you go from level 1 to level 2 to level 3, the system is more flexible, adaptable, and upgradable, but it's more complex, and thus more brittle to attack. Sorting out how to handle this sort of thing is going to be a big challenge as IoT pushes into more devices.
Encrypted and authenticated data on the bus won't happen anytime soon for cost reasons. Filtering the commands the controller can put on the bus seams reasonable, but would only be useful, if implemented on a second controller (probably won't happen, either).
I think the best approach is to secure the internet connection properly. Don't permit incoming connections at all and just permit a single outgoing TLS connection to the server of the manufacturer, define a very simple protocol and spend enough time to be sure the client is secure and validates everything.
Given the risks to safety, it's necessary to use defense in depth and secure every layer by air gaps where possible, and a strict message whitelist where not. This might add $100 to the cost of each car, which is a ton of money when multiplied by millions of cars, but it simply has to be done.
Absolutely. But I can think of one very easy check that would solve many potentially serious problems.
Disable remote operation of car hardware when a conscious human is detected at the manual controls.
For some reason, this reminds me of Star Trek episodes where the crew has to transfer operation control of the Enterprise from the bridge down to engineering, or to another Starfleet ship. Even on a sci-fi television show, whenever that happened, it seems like they always had to enter a secret security code or have multiple bridge officers give their authorization codes.
It speaks poorly of your product design when writers for a television show give more thought to security than you.
It's usually convenient to a plot to have characters do things.
In real life, people generally prefer not doing things.
Which isn't meant to excuse a problematic implementation like is seen in this article, I'm just not sure the writers were actually sweating the system details when they did that stuff.
While I don't think the original writers paid much attention to any of that, by the time Star Trek: the Next Generation began, computer security cracking was present in the popular culture. That's how the invading Borg were defeated, after all. At some point, when the plot for a current episode demands that it be possible for a ship to be controlled remotely, they then have to ask the continuity expert how to fix it so that the newly introduced thing doesn't significantly impact previous canon. That burden adds up across multiple seasons of multiple spinoffs.
The plot solution didn't even have to make sense. All they need is some technobabble, ready to spout for any fan wearing plastic ears who might stand up at a con and ask, "If Enterprise had capability X in episode Y, why wasn't that used in episode Z?"
In this case, it is very reasonable that someone, somewhere, might have asked, "What should we do if this command is used while the owner is driving along a busy highway at 70 mph, and executing it would stall out the engine?" This is a question that would provoke a stop-and-assess moment in even the most dysfunctional software company I have ever worked in.
From the architectures we typically see for in-car computer networks, it looks like no one is asking these questions.
I was addressing the question of wireless access to vehicle systems, not trying to justify any particular feature that might be included in such an implementation.
