The hack of a Tesla Model S back in September 2016 grabbed considerable headlines. Researchers from Chinese tech giant Tencent, an investor in the OEM, were able to remotely control features like door locks, seats, indicators and, most worryingly, the brakes.
Less than a year later, in July 2017, the same team was able to hack a Model X, with similar results. A statement from Tesla assured owners that the risk of such events occurring in the wild was very low, and Tencent affirmed that its complex methods required certain circumstances which would be difficult to replicate. The statistics back Tesla up – to date, there have been no malicious examples of car-hacking.
If you have a process with access to the CAN bus running, this could potentially be used to take control of a vehicle. There’s no way an infotainment system should be able to access critical systems on the CAN bus, be it directly or indirectly
That said, one detail to emerge from the hacks neatly highlights a central security concern for OEMs as vehicles become hubs of connectivity. In both incidents, the hackers exploited the in-vehicle web browser built into the infotainment system. Today, these infotainment systems are virtually the norm for new vehicles, and customer appetite for connected features in their dashboards and instrument clusters is only set to grow. The question for OEMs is, how can these functions be provided without creating new security risks?
To answer this, it is important to understand what happened in examples like Tesla’s. Chuck Brokish, Director of Automotive Business Development at Green Hills Software, explains that in this case, the oversight lay in enabling access to the vehicle’s CAN bus, from where functions can be controlled, through the infotainment system. “What the previous hacks have demonstrated is, if you have a process with access to the CAN bus running, this could potentially be used to take control of a vehicle,” he says. “In this case, it was an example in which access control was not limited. And there’s no way an infotainment system should be able to access critical systems on the CAN bus, be it directly or indirectly.”
The fundamental concern, and one which the industry has been aware of for some time, is that as more vehicles get connected, so too do they become more susceptible to vulnerabilities. “The amount of code that’s getting put into vehicles, and the features that are being added, is growing at an alarming rate,” says Brokish. “Every line and module of code that you add is one more opportunity for vulnerabilities. More features mean more attack surfaces.” Modern vehicles can use over 150 million lines of code, and an infotainment system alone can use over 20 million lines.
What’s more, modern dashboards are characterised in part by a complex interplay between infotainment systems and instrument panels. “When we talk about safety critical, the dash today is far more complex than traditional dashes have been,” says Brokish. “There is far more content, because alongside the critical indicators and gauges, there is additional information from the infotainment system, such as mapping, turn-by-turn directions, radio, climate control, and other vehicle information.”
The solution to prevent incidents moving forward, says Brokish, is strict mandatory access control. It must be determined whether a function is safety-critical, and whether it needs access to the CAN bus or other critical vehicle systems. If a function doesn’t require it, its access must be restricted. To that end, the company recently unveiled its Connected Cockpit Vehicle concept, developed in collaboration with Renesas Electronics and others. The key element from Green Hills is the INTEGRITY real-time separation kernel – an operating system which achieved the highest level of safety and security certification in the world, and which separates tasks.
The dash today is far more complex than traditional dashes have been. Alongside safety-critical indicators and gauges, there is additional information from the infotainment system, such as mapping, turn-by-turn directions, radio, climate control, and other vehicle information
One of the main challenges in running safety-critical tasks in parallel with non-critical ones is guaranteeing the required resources are available for the former, particularly when resources are shared between the two. Consider a camera, says Brokish: informational advanced driver assistance systems (ADAS) may make use of the same vehicle cameras as a rear-view system, the latter being a safety-related function. Equally, the infotainment system makes use of the same audio system needed for warning-based chimes from a safety function. Not only must the resource be available, but it must be free from interference.
“Another shared example is graphics,” says Brokish. “If a vehicle is to use graphics for safety-critical functions alongside non-critical functions, such as map rendering or showing the label of the music being played on the infotainment system, it cannot afford to have non-critical functions occupying the graphics engine to the detriment of the safety critical tell-tales the driver needs in time. And so mandatory access control determines what functions have access to resources.” Graphics become particularly complex as vehicles adopt 3D digital gauges, which compared to their simpler 2D predecessors look far more realistic and can convey far more information to a driver, including those safety-critical tell-tales.
Another challenge is that as time goes on, vehicle complexity increases the difficulty of proper separation. A fundamental process used by Green Hills, explains Brokish, is the Hazard Analysis and Risk Assessment (HARA), which addresses what functions are running in the vehicle, and whether these can interfere with the smooth running of other functions. “The whole process gets more complicated as more functions are added,” he says, “and safety functions need to be separated not just from non-critical ones, but from each other, to ensure that no one function affects the safe operation of another.
“Proper separation of the non-critical functions can also make this easier when trying to assess what is safety related,” he continues. “If I can guarantee that, for example, my infotainment system is running and is not able to get access to critical busses in the system, then I can remove this from the list of safety critical variables.” For now, however, as Brokish points out, if systems are designed in such a way that they have access to safety-critical busses, then those systems themselves need to be considered within safety-critical assessment, whether they’re contributing to safety or not. What’s more, certain features could move from convenience to safety-critical – for example, efforts are under way in the industry to remove side mirrors and rely instead on cameras, which transforms the role of surround view cameras. When this happens, those cameras and displays transition from informational convenience functions to safety-critical functions.
The amount of code that’s getting put into vehicles, and the features that are being added, is growing at an alarming rate. Every line and module of code is one more opportunity for vulnerabilities. More features mean more attack surfaces
Collaboration, suggests Brokish, will only become more important to meet the challenges in complexity ahead. “If you consider how much code is in a vehicle today,” he says, “no one vendor is going to be able to create it all. There are areas of expertise much like you see in medicine today – of course there is a place for a general physician, but in most cases, you’ll end up seeing a specialist. And this is now the case for software vendors.” All of this collaboration, he concludes, must be done with safety and security of the end product in mind.
This article appeared in the Q2 2018 issue of Automotive Megatrends Magazine. Follow this link to download the full issue
