Safety & Security

Secure middleware for IP-based in-vehicle communication

For in-car communication networks, IP is increasingly seen as an option, with security addressed at the network and at the application layer. A middleware handling security issues could drastically simplify the software requirements.

---

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. For full resolution, click here 

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.

The aspects of a secure automotive middleware can be best identified from the application perspective. One major question is how are security parameters set and when.

The use-case driven analysis differentiates between pure in-vehicle communication and potentially insecure communication between ECUs and consumer electronics (CE) devices. The project focuses on requirements for automotive security, on possible IP-related threats, and on requirements that are actually common and needed for in-car communication. This discussion must also clarify the dynamic behavior of communication, e. g. the frequency of an individual message and other relevant dependencies between communication partners. Taking the security dimensions from ITU-T Recommendation X.805 as a basis for protection goals, expert discussions brought up an estimation for in-vehicle security needs:

-       Integrity, authentication and availability must be guaranteed whenever communication is relevant for safety functions. This is especially the case for communication in the powertrain or driver assistance domain.

-       Further security dimensions such as privacy (e. g. for position and speed) are relevant as soon as the car network gets connected to a not trustworthy network.

For addressing these requirements, adequate security mechanisms must be identified. One of the objectives should be to use existing and standardized protocols without dissenting from the standard to profit from the approved functionality. The applicability must be of course demonstrated in an automotive environment. The following section lists our preliminary findings on such standardized protocols.

In an IP-based environment there are several possibilities to ensure security in a system. One solution for security in such a system can be IPsec. IPsec is part of the OSI layer 3 and is used to secure IP-communication by authenticating and encrypting each packet of a data stream. The system can use IPsec to secure an end-to-end communication, e. g. ECU software updates or diagnosis. As the middleware normally is part of the OSI layer 4 to 7, IPsec can only be used by the middleware by forcing the underlying network to use IPsec for end-to-end communication. This can be achieved by the new connection latching feature of IPsec.

Another solution that can be used for middleware security is the transport layer security (TLS) protocol. Most commonly TLS is used as an application library to protect TCP communications. When using it in conjunction with a middleware, TLS should be part of the middleware and not the application. In this architecture the middleware will support security requirements associated to communication requests. This allows every application using this middleware establishment protected communications between two endpoints. Currently TLS is used in web browsing, electronic mail, internet faxing and instant messaging. All these are part of the communication scenarios in today’s cars. Additionally TLS can be used to allow communication to the backend, car repair shop or Car2X.

At the application layer there are several possible protocols, which can be used by the middleware to offer a security service. We will detail two important candidates. The secure shell protocol (SSH) allows data to be exchanged using a secure channel between two networked devices. This protocol can be used for diagnosis in car repair shops in order to check if an update was successfully executed on an ECU. It can also be used to access or update a file directory, e. g. map data or manufacturer specific data. Another protocol is the secure real-time transport protocol (SRTP) that is used in IP telephony for secure transmission of voice traffic between the participants. It can be used for streaming audio from a handheld device to the car or for a secure transmission of voice traffic between the car and a participant, both connected via internet.

At the moment these and other protocols are reviewed in terms of usability in an automotive environment. The goal is to create a security building set that is maintained and made use of by a secure automotive middleware for IP-based in-vehicle communication. This security building set must include all mechanisms that are needed to establish every identified security dimension for communication between differently powerful ECUs.

The tasks described in this article are performed within SEIS – Security in Embedded IP-based Systems – project. The research project explores the usage of the Internet Protocol (IP) as a common and secure communication basis for electronic control units in vehicles. The project is partially funded by the German Federal Ministry of Education and Research (BMBF). Partners involved in the SEIS project are Alcatel-Lucent Deutschland AG, Audi AG, Audi Electronics Venture GmbH, BMW AG, BMW Forschung und Technik GmbH, Continental Automotive GmbH, Daimler AG, EADS Deutschland GmbH, Elektrobit Automotive GmbH, Infineon Technologies AG, Robert Bosch GmbH, Volkswagen AG, the University of Erlangen-Nuremberg, the Karlsruhe Institute of Technology, the Technical Universities of Chemnitz and Munich, and the Fraunhofer Institutes for Communication Systems ESK and for Secure Information Technology SIT. The project is coordinated by BMW Forschung und Technik GmbH in Munich.

The SEIS project is divided into six subprojects. The first subproject, an analysis of the automotive specific requirements, is already completed. Currently, several subprojects explore possible solutions on different layers.

Figure 3: Overview of the six subprojects within SEIS

Subproject 3 explores system software for in-car communication. Therefore different available middleware solutions are investigated towards their applicability for in-vehicle usage. A possible middleware solution should not only support basic functionalities, but should also be part of the security architecture and support security relevant features. Research findings will be published consequently.

For more information about the SEIS project please visit http://www.eenova.de/projekte/seis/

Gerrit Grotewold is project enineer at SOLIN AG. He supports BMW Group Research and Technology at the SEIS project.

Kay Weckemann is researcher in the field of IP-based system softwares for BMW Group Research and Technology GmbH.

Pedro Sebastiao Correia is doing research on embedded IP-based systems at Audi Electronics Venture GmbH.

Alexander Camek works for fortiss gGmbH where he conducts research on embedded IP-based Systems.

NXP

Analog Devices

HEV

Bosch

Vector Informatik

Continental

Infotainment

RTOS

QNX

FlexRay

Daimler

Hammerschmidt

BMW

National Semiconductor

International Rectifier

GPS

Fraunhofer

Powertrain

Audi

E-car

Linear Technology

China

Automotive

CAN Bus

Ethernet

Battery

Security

Autosar

Infineon

Power