In short, the focus has to be on brakes, steering, and to a lesser extent, throttle. Listing a lot of other stuff just adds noise to the discussion.
The question of what will be possible or not in the future isn't the issue. The future will have to be taken care of, in due course. The question at hand now is how vulnerable vehicles are, present tense, to remote hacking into the critical system (steering, brakes, throttle, not the stereo). It goes without saying that as new capabilities are added to cars, for safety, efficiency of operation, or convenience, new attack vectors will emerge that will need to be addressed. We need not assume right now that these eventual vulnerabilities will go unaddressed.
That's the way engineering of new things has always evolved, after all. You design something new, then you do your best to debug the new gadget before putting it on the market. Unless we're to believe that engineers are unable to discover vulnerabilities, and why that would be the case I don't know, then this network connectivity is just another new aspect to debug thoroughly. And yes, things are missed from time to time, and they have to be fixed quickly when this happens.
As to telematics hacking, that's not a major safety concern, unless you show that OnStar (or other) can incapacitate the brakes, steering, or throttle. Can it? It is probably possible to shut the car down remotely (anti-theft), but fortunately cars can stop passively, without incurring a huge risk. On the other hand, whether the hacker can determine your location, or whether your engine warning light is lit, is more of a privacy issue at best. AND, any car owner can incapacitate that OnStar system. Find the access panel, probably in the trunk, and disconnect it.
Only a matter of time, do you think? What happens when cars become just a "thing" -- an end node -- on the Internet of Things, as this newly formed US Consortium is working toward? I bet wireless remote hacking will be possible. Researchers from the CAESS Center for Embedded Automotive Systems (the same UofW and UCSD group mentioned in article) say "we can call our car's cellular phone number to obtain full control over the car's telematics unit over an arbitrary distance."
Sorry, Junko, we've been over this already. Local connection to the OBD-II port makes all the difference. Unless you encrypt any content that can go into the OBD-II port, making it essentially useless for its intended purpose, it would be pretty hard to prevent "hacking" when the "hacker" is deliberately allowed to get inside.
This OBD-II port is meant for garages to use, e.g. for troubleshooting and emissions testing. They also have access to brakes, steering, and throttle, and every other system in that car, without needing wires to cause damage.
If you do encrypt that OBD-II port, and then you give garages the private key necessary to decrypt, so they can do their work, then we're back where we are now.
Having remote wireless access to the critical functions, such as brakes, throttle, and steering, through an unencrypted interface, is what has to be shown. If that's available, then that security hole needs to be plugged. But quite honestly, this stream of articles about hacking seems to obfuscate the attack vectors, by including a lot of extraneous information.
Show me where a remote wireless device can impair the function of throttle, brakes, or steering. Leave the rest out. Then we can see if there's a problem to be fixed.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.