"...whether the Internet-connected computers were properly isolated from critical driving systems, and whether those critical systems had “cyberphysical” components—whether digital commands could trigger physical actions like turning the wheel or activating brakes."
Shouldn't this be the most basic design consideration for any company building autos? The liability from litigation should bankrupt any company that doesn't prioritize this.
Well self driving cars should be a load of fun. There will be calls to isolate critical components as well as demands they are accessible to the likes of Law Enforcement so they can disable cars remotely.
So it will take legislation to sort out as liability concerns needs to addressed as well as the demands of law enforcement. Don't think for one minute they will accept self driving cars they cannot disable all of them for "safety reasons". Similar how they excuse options to black out cell service in areas
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.
It probably depends on how the exploit works. If you can OTA update a firmware that allows wireless control, that is a huge flaw.
But this article doesn't really talk about how the exploit is triggered. This is pure speculation, but I bet it requires some physical access to install. And then the wireless control works.
Why do I suspect that? Why else would the journalist have to travel all the way to St. Louis to test it.
Imagine how huge the story would be if these guys disabled a car they never got within 1000 miles of over the internet.
There is probably some CPU in the Navigation/Entertainment display that needs access to the CANBUS for stuff like warnings, speed, airpressures, etc. and also is connected to the UConnect thing for entertainment purposes. You can't airgap because you need the car data.
So the lazy solution is to just firewall it. Make sure the CANBus controller for the entertainment system only sends data and doesn't receive any. Maybe you encrypt all data transfers on the bus for good measure.
But with temp physical access you can reflash that controller to allow it to give commands it receives from the internet connected entertainment system.
Shouldn't this be the most basic design consideration for any company building autos? The liability from litigation should bankrupt any company that doesn't prioritize this.