How many of us remember a time when car windows had to be cranked up and there were no seatbelts to secure us in case of an accident? A “secure vehicle” was one with locked doors.
With the introduction of the Advanced Driver Assistant System (ADAS) — with ABS, airbag, brake control, steering control, engine control, cruise control, stop-and-go, autonomous parking, integrated navigation system (GPS and Gallileo) — there is no question that the ecosystem of the automobile is becoming more interconnected and increasingly complex, but electronic devices have also replaced more trivial functions like light control, air conditioning, power windows, engine starting, door opening, adjustable and heated seats… The list of available options goes on.
Figure 1 shows that each function inside the car is managed by a network of microcontrollers (MCUs) which exchange data and information jointly using the same communication bus: CAN, FlexRay, or LIN for powertrain, chassis, and body electronic functionalities, and MOST and Ethernet for infotainment.1 Those communication buses are currently present in several new-generation MCUs.
Though progressing from a purely mechanical environment to the sophisticated universe of electronics has provided an added value in terms of comfort, as well as active and passive safety for driver and passengers, at the same time — because those engine control units (ECUs) are interconnected — significant security issues regarding privacy and data reliability arise.
For example, some decades ago, CAN was not designed to be robust in terms of security. In fact, any CAN message inside the car communication bus was broadcast to any other component and did not support any authorization, authentication, or encryption protocol.
Modern cars exchange messages using the CAN bus to open doors and start the engine. Those messages are swapped between an ECU inside the car and one inside an electronic key. If this system were compromised, a thief could easily steal the car. Also, a hacker could access the GPS inside the car to monitor frequent locations to find out where the driver is and when he leaves the car unattended.
Furthermore, wireless communication channels such as Bluetooth, GPRS, or UMTS for Internet mobile functions like email, SMS, video streaming, video calls, and so on, have enlarged the “attack surfaces” for hackers who could compromise any communication and driving system, or insert malicious software to steal data like a vehicle’s position in real-time, frequently used routes, and full conversations, by remote access.
By definition, an “open system” is exposed to a continuous increase of attacks through several methods. The incessant evolution of internal and external communication networks inside vehicles quickly reduces the capacity of current security measures to provide adequate protection for these systems.
Until now, only theoretical proposals have been suggested to protect cars from internal and external attacks, and the possibility for hackers to control any driving system (brakes, ABS, airbags, navigation), thus risking the vehicle occupants’ lives, is more real than we have suspected.
Several technical articles have shown that taking control of a car using those attack surfaces is not merely hypothetical.
Two different research groups, one from the University of Washington and another from the University of San Diego, have produced the most famous and interesting works about the topic. They have demonstrated the inner weakness of ECUs with experimental analyses on the security of the modern cars. They revealed how relatively easy it is to take control of a wide range of automotive safety-critical functions, totally ignoring driver input, and how those attacks can be obscured with a complete erasure of any evidence after a crash.2
Just for this reason, in the past few years, several consortia, such as EVITA (E-safety Vehicle Intrusion Protected Applications) and HIS (Hersteller Initiative Software), have been created to suggest guidelines to design and verify systems able to resist intrusion attempts and external manipulations.
Those groups have proposed sophisticated software application models using cryptographic communication protocols, and also have proposed some very interesting guidelines, from a hardware point of view, to build more robust microcontrollers that can avoid illegal firmware alterations, unauthorized intrusions, and illicit misuse.
To read more of this external content and to leave a comment, go to “Silicon vendors get involved.”