Intra-vehicle information security framework

Vehicles are becoming increasingly reliant upon IT and electronic systems. Digital signal and information processing are already widely used in luxury cars, and will become more pervasive across all models during the coming years. IT is also common in car multimedia and GPS navigation systems, while many vehicles deploy digital circuitry to collect data that is later used for maintenance. In the future, there are plans to enable vehicles to communicate with each other and with roadside infrastructure for various purposes ranging from safety to e-commerce.

As the use of electronics becomes nearly ubiquitous in the automotive world, security risks inevitably arise. The components used in any vehicles must be extremely reliable and bug-free, but they must also be extremely resistant to malicious attacks. The importance of the assets that may be involved in a vehicular information technology system, as well as the fact that the owner of the vehicle, who naturally has unlimited physical access to it, may in some cases form part of the threat, make protection of the assets involved even more complex. Then, there are growing concerns about cyber-terrorism, particularly attempts to affect the infrastructure.

The risks involved and their inherent complexity, along with the fact that a vehicle has a comparatively long lifetime (in IT ‘years’), dictate that information security assurance has to be done properly, hopefully from the start.

Inter-vehicle and intra-vehicle security

There are essentially two major domains across which information security concerns need to be addressed. We can term these as either ‘inter-vehicle’ and ‘intra-vehicle’ or, respectively, ‘external’ and ‘internal’. Both domains tend to regard a vehicle’s information system as a single entity, although in practice it is likely to consist of many detached components.

The internal domain concentrates on the ability of in-vehicle components to resist local attacks. By ‘local’, we mean attacks that are not typically launched by communication to and from the external ports of various in-car components (although this is not exclusively the case). They include physical attacks upon the various embodiments of the IT components (both invasive and non-invasive), and attacks on the interfaces between trusted components within the vehicle itself. API attacks also fall into this category, where they involve the exploitation of interfaces between components inside a vehicle.

By contrast, the external domain concentrates on connections between in-vehicle components and entities beyond it. It is concerned with possible attack vectors that involve the exploitation of protocol flaws, either at the network layer or the application layer. An example of an external attack would be the use of a protocol flaw to send a fake hazard message that appears to come from a roadside beacon but is actually from the attacker’s home network. Also covered under the external domain are denial-of-service attacks over network interfaces.

A key difference between the strategies that can be used to combat internal and external attacks lies in the different standards that apply in each domain. Specifically, external domain security relies on hardening the protocols used by a vehicle to communicate with other entities. These protocols must be agreed upon on a cross-industry basis, and therefore, work to ensure their integrity must be based at the same high and broad level. Securing the internal aspects of a vehicular system involves design decisions that are within the scope of an individual vehicle manufacturer to make. This article describes an intra-vehicle information security framework, and therefore focuses on the latter internal domain.

To help secure the vehicular information system within the internal domain, we propose a strategy based on the use of a toolbox (Figure 1). It contains several discrete functions and well-defined APIs, and seeks to relieve client applications from the need to address security concerns involved with the applications, as much as is feasible. The tools provide functions that also help to secure the client-side modules of the car-to-car and car-to-infrastructure systems.

Broadly speaking, the architecture for a comprehensive vehicle security framework should consist of the following two types of components:

• low-level enablers providing core security functionality specific to vehicular environments (i.e., the toolbox); and
• embedded applications that use toolbox components to handle common vehicular use-cases.

The purpose of the toolbox is therefore to provide some common security functions at the highest, most effective level of abstraction, and to implement these functions securely in well-suited embodiments. Detaching security functions from the software that uses them allows developers to create secure applications without their having extensive security know-how and can reduce the ‘attack surface’ of these applications. Let’s consider some applications that emerge from such a strategy.

Secure updates

The firmware in a vehicle’s controllers will probably need to be updated several times during its lifetime. Using an application update enabler, controller code can be updated securely, with authorization done through a central location in the vehicle. This enabler is responsible for:

• obtaining signed code images and destination controllers;
• connecting to controllers to be patched securely;
• providing controllers with a new code image or updated information; and
• updating the registry so that controllers boot properly after updates.

For the enabler to work, an application must be installed on the destination controller that allows the reception and processing of new code information. It is not possible to update firmware code on controllers that do not support firmware updates, other than by connecting to their firmware storage medium using other agents that run an update application and connect to that storage medium.

Secure data logging

The purpose of a secure logging application is to collect, retain and serve back transaction logs of all sorts. For example, the application can be used for:

• drive recording (e.g., logging driving speed, durations and routes);
• inputs to the service and maintenance logbook (e.g., times and odometer readouts at service sessions); and
• the collection of troubleshooting information.

The log information has to be protected from tampering. In many cases, even the entity that generates logged transactions should not be able to remove or modify transactions after they have been recorded.

Part authorization and management

It is often important to be able to tell if parts of the vehicular system are genuine and/or approved. Such verification is important for reasons of safety, liability and maintenance. Even if the detection of a counterfeit (or an otherwise unauthorized) part does not necessitate its extraction or isolation from the rest of the vehicular system, it is often important to note its status so that warranties can be restricted, other components can treat the non-genuine part accordingly, and the service center is warned and may notify the driver. There is now also the option to inform the driver directly that a counterfeit part has been installed in his car.

Theft prevention

The theft prevention application will utilize the tools in the security toolbox to securely and conditionally disable essential vehicle components in certain scenarios that may indicate an unauthorized person is attempting to use the vehicle.

Feature activation

Vehicles are sometimes manufactured with features that are not made available to all buyers. OEMs sell cars that offer different feature sets at different prices, sometimes targeted at different customer groups. Since it is cheaper to design one feature set with various OEM-controlled on/off ‘buttons’ rather than different systems according to each product tier, some features are often designed to be enabled or disabled at the firmware (or configuration data) level. This also allows the OEM to market extended options to the customer after the original purchase.

Inevitably, there will be attempts to subvert the mechanism to enable ‘hidden’ features. The threat is more complex than a car owner attempting to enable features for which he did not pay. In some cases, a car dealership may desire to activate features on vehicles sold to end customers either as part of a promotion or for a fee, but without notifying (and paying) the car manufacturer. A secure system for feature activation (Figure 2) shall on one hand allow a dealership to activate features on cars that it sells, while on the other hand assure that this cannot happen without the permission (or at least the knowledge) of the OEM.

Conclusion

The applications discussed above require an internal information security services framework for vehicular environments. The framework consists of a logical toolbox—a set of logical modules that are installed in a variety of controllers or devices, which provide the security functionality that vehicular applications require.

Discretix Technologies Ltd.
Grand Netter Industrial Zone
Delta Building
Kfar Netter
POB 3641
40593
Israel

T: +972 (0)73 255 8800
W: www.discretix.com