• Print
• |
• Email
• |
• Reprints
• |
• RSS
• |
• 

Page 1 of 2

(Note: This article originally appeared on EE Times Europe's Automotive site.)

Introduction
Focus is pointed on system software for communication within an IP-based in-vehicle network. Thereby security requirements are addressed by an abstraction layer for communication – a secure communication middleware.

The goal of a communication middleware is to offer an abstraction from the underlying communication layers to the application developer. The same should hold true for security mechanism: In order to achieve crypto-agility – i. e. the possibility to easily exchange cryptographic algorithms if needed – a suitable security abstraction is required. While an application developer decides on security requirements, the communication middleware abstracts from the actually used security mechanisms.

Fig. 1. IP will be the convergence layer of in-vehicle networks.

In today's in-vehicle communication systems, security is addressed both at application layer and by other means, e.g., network architecture. Application layer security solutions offer good individual adoption per application on the one hand, but on the other hand require each application to use and bind security libraries, which practically leads to a wide variety of security bundles over the system. Offering security as a service of an underlying middleware layer would homogenize the overall set of security features and thereby increase maintainability and crypto-agility.

Figure 2: Relevant functionality of an automotive communication middleware

The following section gives an introduction to the relevant automotive requirements. Afterwards, we motivate our approach towards a secure middleware solution. The article concludes with an overview of relevant existing security protocols we will be investigating for adoption within the next months.

Basic Automotive Requirements
What are the minimal requirements of a middleware for in-vehicle usage? The project aims at a middleware that at least supports remote procedure calls (RPCs), notifications, a mechanism for service discovery and optional means to secure communication.

For non-functional requirements, the main challenge is scalability in terms of required hardware power and number of electronic control units (ECUs). In today's cars there is a wide variety of ECUs with CPUs of different processing powers. There are needs for communication of an up-to-date 32-bit ECU with a small 16-bit or even 8-bit sensor device. Therefore a middleware for today's vehicles should offer a full featured specification for powerful devices and at the same time provide an interoperable feature subset, which supports the communication needs of small sensor devices.

Scalability in terms of ECU numbers is also challenging. The number varies from a few to 70 devices in today's premium cars. Another issue of scalability is that a middleware must support sub-network operation as this is an important feature for addressing energy efficiency from the E/E perspective. It should be possible to shut down parts of the communication network dynamically without affecting the secure operation of the vehicle.

Page 2: A Secure Communication Middleware

Page 1 2