I agree Tom, it will take long time...I predict some driveless highway system will appear in 20 years or less...and yes it might take 50 years for all cars to be driverless (it won't be completely driveless, you will might still sit behind the wheel but you will be on autopilot as planes are) Kris
Krisi, I suppose you're right in saying driverless cars "will happen," but the question is "When?" Earlier in this chain, I noted I first heard a confident prediction that they'll appear by 2000 (that was at the NY World's Fair in 1964). I've heard about them ever since, and the technology -- as noted in several recent articles on EE Times -- suggest they are ever-closer. But the enormity of the task of making them work on a practical basis seems like an awfully big mountain to climb, even in the US. Most cities and towns here now struggle to fill potholes, online maps are notorious for delivering you to streets that don't exist, and navigation systems don't always know about changes in roadways or new construction. In sum, I'm not holding my breath for this. I heard about this a half-century ago, and I wouldn't be surprised if they're still a half-century away.
We might complain, be concerned etc but this techology will happen...subway in Vancouver where I live operates without a driver, planes fly on auto pilot, Google has its driver-less cars...so these things can work...fully networked car will too eventually, in fact my bet is you will have to pay a premium to have the networking fundtion turned off (the same way as you have to pay your smart meter disconnected)
As I really have the insight into automotive developments: it's less about badly designed code - it's more about poorly designed systems. Too much time wasted on inefficient processes and "management hobbies" leaves too little time for good system design. Other constraints add to this.
There are already means available to protect - to some extend obviously not implemented in the 2 vehicles under test - against tampering of messages.
What will always be an issue is blocking the CAN (read: communications link) as described. (You might as well simply short CAN+ and CAN- with the same effect.) But a stationary vehicle is considered the safe state by the authorities so this is not really an issue. And every ECU should have fault strategies for communications failure. See about "poorly designed systems".
A "flipping" dashboard display may be annoying but isn't really a safety issue. (Safety assessments as per IEC 62508&ISO 26262 are quite another issue.)
For state-of-the-art security, each and every message considered safety-critical should be safeguarded. IMHO checking for too many messages per time interval (often forgotten) as well as message counters, additional CRCs, "secrets" (that is information not transmitted via the communications link) shared only between sender and receiver of critical data are some of the means.
I am in agreement. All this article illustrates is that local, physical access to a standardized physical communications port that is, by design, intended for easy access to numerous diagnostic and test functions of a vehicle is possible by people with communications and some embedded programming skills. And, what is the primary defense against malicious attack - control of physical access, of course!
Why else do companies put locks on the doors of their servers farms, or lock up their backups? Attempting to make the leap from this example, to postulating that the same or worse could be done through a wireless communication interface designed for different purposes, like OnStar, for example, is at best HIGHLY speculative and unlikely. If one allows a malicious person such unlimited physical access to diagnostic/test functions as this, they also could just as easily implement real physical sabotage with even less difficulty. Until someone actually demonstrate the ability to take over control of a vehicle's primary control systems of engine control, brakes, lighting, or steering through a remote wireless interface such as bluetooth, cellular modem interfaces or satellite links, count me in with the gang who feel this is just more hype to induce fear in the uninformed. The article basically shows us that with a CAN bus adapter and some code anyone can plug into an OBD-II port and snoop around. Guess what, many have been doing this for years now!
I would say that part of the issue is in the theoretical possibility as much as with any demonstrated vulnerability. I had always thought that these semi-automated cars would fail safe or could easily be over-ridden by the driver. This video does demonstrate that failure isn't always in a safe mode and manual override isn't necessary possible.
Attack vectors and system exposure are both important parts of the "car hacking" equation. For today, the safety critical systems aren't wireless. My understanding is that critical systems are on a different bus than non-critical, like entertainment and navigation. Please correct me if I'm wrong on that. Regardless, that these particular systems can be manipulated without authorization means that they will be vulnerable at some point.
I also don't think we should dismiss the potential for harm in accessing non-critical systems. Messing with GPS or remote ignition could strand someone or get them lost. That may be more on the level of mischief than danger, but there are of people that like to engage in mischief. People have made fake 911 calls leading to a SWAT team showing up at houses to very surprised residents. Onstar like systems could be used to do the similar things - send rescue crews out to spoofed crash reports.
If you regard the latest reseach by Charlie Miller, a security engineer at Twitter, and Chris Valasek, director of security intelligence at IOActive, as some kind of a tool to judge whether your current car is safe or not, of course, this whole thing reads like just a scare story "without any proof."
I find that unfortunate and disturbing, because that would be, in my opinkion, entirely missing the point.
The research about the future. This is about how the next-generation connected cars -- which will have more exposure to the external world than ever -- should be protected from potentially malicious attacks.
As the two researchers noted in their paper:
The hope is that by releasing this information, everyone can have an open and informed discussion about this topic. With this information, individual researchers and consumers can propose ways to make ECUs safer in the presence of a hostile CAN network as ways to detect and stop CAN bus attacks. This will lead to safer and resilient vehicles in the future.
As *not* an automotive engineer, but as an embedded firmware controls type of guy, I would agree with Bert's last paragraph - a "Show me the money" type of thing. If steering, brakes or throttle aren't affected, or can't be controlled, then I, too, see no real threat. However, show me that happening and would definitely sit up and take notice!
I agree with this. I've seen these people "hacking" cars in the news a lot recently, but they are given time inside the car to attach a computer. To me, this isn't as big of news as it sounds. Sure it is interesting that they are able to mess with things, but it is like saying my computer is at risk of hacking as long as I give someone full and unhindered physical access to every component.
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. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.