Incidents of car-hacking have grabbed plenty of headlines in recent years, rightfully prompting concerns for tomorrow’s connected vehicles. Whilst it’s true that all known car hacks to date have been research-based, and performed in controlled environments, it’s not hard to imagine a future where drivers will face threats in the wild.
That’s according to Joe Fabbre, Director of Platform Solutions at Green Hills Software. The way he sees it, these threats will largely fall into two categories. One is the type that nobody hopes to see – a malicious attack, launched to hijack and even purposely crash a vehicle on the road. Terrorist organisations and organised crime syndicates are just two examples of groups who may seek to wreak havoc.
The other type is less extreme, and is often seen in consumer and IT markets. “The same types of things we’ve seen in the enterprise world are possible,” he explains. “Attackers in this case would be seeking financial gain. Depending on which analyst you believe, there could be over a hundred million more connected cars on the road by 2020, making them a very attractive target for things like botnets, which can steal personal information. And it’s very easy to imagine a future where people will have credit card numbers and other personal information stored on computers in their vehicles for convenience.”
In this context, botnet refers to a network of internet-connected devices which, unbeknown to their users, have been infected with malware which can receive and carry out instructions from a ‘botmaster’. Botnets are one of the most popular methods in modern cyber crime, and when designed well, they can go undetected for a long time.
But it’s important to distinguish one threat type from another, says Fabbre. Whilst losing a credit card can be a major inconvenience, insurance mechanisms are in place to prevent loss, and people ultimately move on with their lives. Conversely, were a hacker to suddenly gain control over a car, or a number of cars, the consequences for the drivers, pedestrians and other road users may well prove irreversible.
The question for Green Hills and others is, how do you make such hijack scenarios impossible? The company’s expertise in embedded software means it is positioned well, but what’s really needed, suggests Fabbre, are much stronger policies and standards. “When I think about the safety and security standards in the automotive space today,” he says, “I don’t think they are strict enough to deal with well-funded attacks which are intentionally trying to break systems, and do harm to people.”
Look to the skies
Luckily, there are already safety and security standards out there which, in Fabbre’s opinion, have the level of rigour which the automotive industry will need. In the avionics industry there is a safety standard called DO-178C, which is the document used to approve software used in commercial aeroplanes. Using the document, software-based systems on planes can be placed in one of five categories, from A to E. Anything controlling or monitoring safety-critical functions is classed as level A.
“That’s the level of rigour that I feel we ought to be applying to safety-critical internet-connected devices, and certainly things like autonomous cars,” he says. Green Hills’ ‘INTEGRITY’ real-time operating system (RTOS) is, according to Fabbre, the result of a laser-sharp focus on safety since the mid-1990s – an OS built from the ground up with safety in mind. Vulnerabilities in the lowest layers of software architecture can put an entire system at risk. For an effective security architecture within a critical system, he says, an operating system needs to be designed with two things in mind.
Firstly, there can be no vulnerabilities in the operating system – the code must be fully understood. It has to be rigorously evaluated and tested by external trusted certification organisations. This type of rigour applies not only to the code for the operating system, but also any safety or security critical applications hosted on that operating system.
It’s very easy to imagine a future where people will have credit card numbers and other personal information stored on computers in their vehicles for convenience
Secondly, an operating system must be able to guarantee separation and isolation of critical and non-critical software components. “If you look at a car’s in-vehicle infotainment system, composed of graphics drivers, multimedia codecs, and all of the other software that allows you to run things like Pandora and take phone calls in your car,” he says, “that’s a lot of extremely complex code, made of millions of lines. That software is simply too big and too complex to be evaluated to the degree I’m talking about. That kind of software needs to be isolated away from the critical software that does go through the rigorous safety checks.”
Green Hills’ research over the last four years shows a repeated failure to achieve this separation, with hackers penetrating vehicles through the infotainment system as one common attack point. One example came in September 2016 when a team of researchers in China took remote control of a Tesla Model S from 12 miles (19km) away, successfully interfering with a number of features including brakes and locks. These are clear indications that attackers were able to issue commands on the Controller Area Network (CAN) bus of the car, indicating a failure of separation within the architecture. Moving forward, how can manufacturers ensure the same doesn’t happen to them?
Strict division
There are a number of ways to achieve separation, says Fabbre, but the volume of new technology and features coming together inside the car in conjunction with more capable and powerful processors means that OEMs favour software-based separation over hardware-based separation: “Software separation grants much more freedom and flexibility of design, compared to hardware-based separation that requires more space and power for additional ECUs inside the car.”
In today’s high-end luxury cars, over one hundred ECUs run hundreds of millions of lines of code. Continuing down that path is simply untenable. Carmakers will have to reduce the number of ECUs while simultaneously growing the software content
This is challenging enough, but OEMs now face further challenges as they seek to further consolidate existing mixed criticality functions within the vehicle.
“In today’s high-end luxury cars, there are over one hundred ECUs running hundreds of millions of lines of code,” he explains. “Continuing down that path is simply untenable. Carmakers will have to reduce the number of ECUs they put in cars while simultaneously growing the software content. There’s some debate about how far we can go – some say we’ll end up with three of four super-computer type systems. My guess is that we’re going to end up somewhere between that and where we are today. I question whether we can really get down to single-digits, but perhaps we can.”
Function consolidation therefore needs to be done safely and securely, particularly as advanced driver assistance systems (ADAS) are deployed in increasingly high-volume models. Along with separation capability, OEMs need to identify the critical components within the car, and with which other pieces they need to communicate.
As Fabbre points out, there is a risk that ECUs running safety or security critical code may be combined with ECUs running insecure code that has not been evaluated with the same rigour. The company’s INTEGRITY Real-Time Operating system was developed to fix this exact problem, enabling safety-critical components to run alongside other non-critical internet-connected components running huge code bases on operating systems such as Linux, or Android.
“This allows for all the functionality we’d like on our centre console,” he says, “but it’s guaranteed to be kept safe and secure, isolated within its own partition, such that it cannot interfere elsewhere.” Once again, Fabbre stresses, the key to designing this architecture is holding it to a higher benchmark.
Separation is a matter of security, and just like safety standards such as DO-178C exist, so do higher security standards. In the case of security, there is an international standard called the Common Criteria, which rates software components against ‘Protection Profiles’ – in this specific case, the Separation Kernel Protection Profile. Results range from Evaluation Assurance Level 1 to Level 7, where 7 is the highest.
“Once you become involved in seeking higher levels of assurance, the government becomes involved,” says Fabbre. “The National Security Agency (NSA) spent 18 months performing penetration testing on INTEGRITY.” INTEGRITY was eventually awarded an EAL 6+ certification, or ‘High Robustness’, deemed suitable for use in a hostile environment featuring well-funded hackers out to attack a system’s security policies. By contrast, he says, other operating systems that have gone through the same process have never achieved ratings higher than EAL 4+, or medium robustness, and not intended for use within a hostile environment.
“They’re only intended to protect against casual or inadvertent attempts to breach the system’s security,” he concludes. “This minimal level of assurance is not enough against hacks that could crash tens of thousands of cars at the same time.” One can surely guarantee that much of the public will feel the same way, as connected cars and autonomous vehicles appear on our roads in greater numbers.
This article appeared in the Q1 2017 issue of Automotive Megatrends Magazine. Follow this link to download the full issue.
