Gone are the days when cars were only used to commute and had a radio or a CD player in the name of multimedia. Today's cars have the capability to be connected to devices both inside the car and on the Internet. They typically have 50-70 electronic control units (ECUs) running various functions and providing comfort, reliability, and safety. It is also now possible to stream personalized content via the Internet, keep in touch with friends, and shop online—all from inside the car.

This advancement does not come without its can of worms; a connected car directly or indirectly linked to the Internet comes with the high risk of malware attacks in the form of malicious code or data. A malware attack could force a vehicle to behave not as intended, experiencing sudden braking, door opening, or failing of critical safety systems such as airbags.

Carmakers are fully aware of these threats and are finding ways to identify, prevent, and resolve them. One way of addressing this would be by building a sound architecture and methodologies.

Connectivity paradigms

Traditionally car networks were confined to ECUs inside the car, which were connected with automotive networks such as controller area network (CAN), FlexRay, and local interconnect network (LIN). However, cars today are connected to devices and carmakers’ portals that provide features like e-Call, remote diagnostics, and data exchange to and from a car. Cars of the future will go one step forward and connect to other cars and exchange data about the operating environment.

Data intensity in modern cars

With advancements in infotainment and connectivity, the data intensity of cars has dramatically changed in terms of nature, quantity, and directionality.

These data can be split into the following categories:

• Data inhaled: Data received by the car from the environment via sensors or the Internet. Traditionally, automotive software was concerned only with data received by an ECU via sensors or other ECUs. ECUs, however, may not have been designed to examine every CAN packet received. This risk is further accentuated as inhaled data include data from the cloud or data that could be injected into car network using malicious software sitting on the connectivity interface

• Data processed: Data that goes into various computations on ECUs or user data churned on infotainment ECU. Since the inhaled data may be unsafe, it may lead to errors in data processing. Telematics and infotainment are vulnerable to code tampering and user data manipulation

• Data exhaled: Car and driver behavior data that may be processed in the cloud to deliver a variety of services including customized insurance solutions, targeted content, and advertisements.

Potential risks

As cars are getting connected, both to devices and the external world, the nature and threat of security risks is also changing. For instance, cars interact with the environment through sensors and actuators. Therefore, car security needs to consider security of data and the environment around the car. Also, prevention and real-time detection of security threats needs to be given more importance.

These potential risks can be divided into following categories:

• Safety: Security vulnerability leads to compromised safety of critical systems, putting the occupants, those outside, and the environment at risk

• Nuisance: Affected non-safety-critical systems could cause cars to deny services or perform undesirable operations

• Privacy: Vulnerability could expose personal information that may be misused or manipulated

• Financial: Financial loss in the form of warranty manipulation or extortion.

Architecture options

Security vulnerabilities increase with an increase in interfaces that enable cars to connect to devices or external networks. One key architectural approach is to minimize the interfaces and consolidate those into a "Command Center," which would act as a secure, intelligent gateway between the car network and the external devices or networks. The approach can better guard against malicious or sensitive data from being inhaled or exhaled, respectively.

The Command Center scheme can include various strategies to handle security risks such as implementing a firewall to provide secure access to the rest of the network.

The following are the key elements of such an approach:

• Protected key entry points: connectivity based on wired and wireless interfaces

• A “closed system”: pre-configured firewall providing restricted access

• Fine-grained user access control: near zero lifespan for elevated privileges.

The methodology

A sound engineering approach is also crucial to mitigate security risks at every step of system design. Carmakers and others can consider the following engineering methodologies and design steps to ensure secure connectivity:

• Interface risk analysis

• Functional safety analysis

• Defensive programming.

Interface risk analysis

The process of interface risk analysis includes looking at every system interface involved in connecting a car to a device or cloud. The first step is identifying all interface end points including network end points, device and wireless interfaces, as well as bus connectors. The second and third steps identify the attacks and potential security issues arising out of these attacks, respectively. Once interfaces have been analyzed, appropriate design strategies can be applied.

Functional safety analysis

ISO 26262 provides methods to realize the safety requirements within the system or subsystem. It describes safety analysis methods like Hazard Analysis and Risk Assessment, Failure Mode Effect Analysis, Fault Tree Analysis, and Criticality Analysis.

The automotive industry should adopt functional safety concepts to assess security analysis. On completion of safety implementation, a safety case with an argumentation is built, which is supported with evidence and demonstrates system safety. This can be extended to security, and such “security cases” could include:

• Evidence about security behavior

• Identification and analysis of hazards, threats, and vulnerabilities

• Compliance to security standards.

Defensive programming

Defensive programming is a practice followed in safety-critical embedded systems. It ensures continuing function of software even during unforeseen usages. In a security context, such unforeseen usage may be because of manipulated data coming from sensors or car networks. Certain principles of defensive programming, such as “all data is tainted until proven otherwise,” are powerful means of avoiding software malfunction even in the case of malicious input.

Putting it all together

Modern cars will continue to be increasingly connected and exchange data. However, to make cars impervious to cyber attacks, a vehicle’s security architecture needs to be fortified. Command Center and robust engineering methodologies will make this possible.

This article was written for Automotive Engineering by KPIT's Ravi Pandit, Chairman & Group CEO, and Omkar Panse, AVP, Infotainment Practice.