SEVECOM
Overview
Vehicular communication (VC) is able to extend the safety features of vehicles, thereby making driving safer by exchanging messages about status and dangerous situations between all traffic participants. Additionally, VC can make travelling more effective and more comfortable by, for example, recognizing traffic jams and distributing this information to following vehicles or simply establishing internet access for the occupants. Therefore, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication are recent research topics and their deployment is pushed to develop the next generation of intelligent vehicles within the next years. But in addition to the new features and possibilities of VC, new challenges and threats appear and have to be addressed during the development process of VC networks and systems. Besides the permanently changing structure of the vehicular ad hoc network (VANET), malicious nodes can start a variety of attacks ranging from faked messages, replay and Sibyl attacks to network jamming in order to gain some kind of advantage. Also, privacy concerns arise, since messages cannot be encrypted in many cases. This allows eavesdroppers to gather sensitive information and maybe track vehicles over a long period of time. To develop solutions for these issues the SeVeCom project was founded, supported by the European Commission. The project started in February 2006, the final review took place in Brussels in April 2009. Its main goals were to secure V2V and V2I wireless communication and propose mechanisms to preserve the privacy of the involved participants.
​
SEVECOM
Developed by
Project Status
TomTom, Nspyre, TNO
Demonstrated
CONTACT
Related Projects
-
NOW
-
esafety projects
-
CVIS
-
SAFESPOT
-
COOPERS
-
COMesafety
​
Objectives
​
SeVeCom addresses security of future vehicle communication networks, including both the security and privacy of inter-vehicular and vehicle-infrastructure communication. Its objective is to define the security architecture of such networks, as well as to propose a roadmap for progressive deployment of security functions in these networks.
​
Partners
​
-
Trialog
-
Robert Bosch GmbH
-
Budapest University of Technology and Economics
-
Daimler AG
-
EPFL
-
CRF
-
KU Leuven
-
Ulm University
-
eSafety
-
Information Society and Media
-
Sixth Framework Programme
​
Inputs
​
On Board Unit (OBU)
-
ITS G5 OBU
-
Smart Phone, PDA
Road Side Unit (RSU)
-
ITS G5 RSU
Data Processing Hub
-
The current version of the architecture contains the following modules:
-
Identification & Trust Management Module
-
Privacy Management Module
-
Secure Communication Module
-
Tamper-Evident Security Module
-
In-car Security Module
Some of the requirements of the analysing architecture are as below
-
All parts comprising VC protocols, system architectures, and security mechanisms should be standardized, as a VC security system cannot be based on a fixed platform but instead has to be flexible, with the possibility to adapt to future VC applications or new VC technologies.
-
Communication Stack Integration: To be independent of the actual communication stack, the integration of the SeVeCom security system into the protocol stack is based on a hooking concept, inspired by similar architectures such as the Linux Netfilter kernel subsystem. Inter Layer Proxies (ILPs) are inserted at several points in the communication stack. Every ILP maintains a list of callback handlers that are to be notified of certain events. Thus, whenever the SeVeCom system is ported to a new platform, besides adapting to different packet formats, only the ILPs and the convergence layer have to be modified.
-
Hardware Security Module: The purpose of the Hardware Security Module (HSM) is to provide a physically protected environment for the storage of private keys and for the execution of cryptographic operations using them. (1) The HSM must be tamper resistant, to some extent. (2) The HSM must have an API (Application programming interface), through which it can provide services to the other modules of the security architecture that run on the OBU
-
VC systems need access to the in-car network and sensors that observe the current status of the vehicle and the environment. This enables the VC system to process signals such as emergency braking, airbag activation, and slippery road detection, thus greatly contributing to the avoidance of accidents and improvement of road safety.
Assets
-
Tamper Evident Security Modules (TESMs)
-
Smart Cards (Sim Cards)
-
IBM 4758 Cryptographic Coprocessor
-
ECDSA for digital signature generation
-
ECIES with HMAC-SHA1 and AES-CBC for encryption
​
Services
Achievements
-
Using Psuedonym Manager
-
Tracking of vehicles over a long period of time is prevented
-
Cryptographic signatures are useful in recognizing attacks
​
Limitations
Services related to the below areas are to be provided
-
SOS services
-
Stolen vehicles tracking
-
Map download/update
-
Intersection collision warning
-
Vehicle-based road condition warning
-
Electronic license plate
-
Road surface conditions to TOC
-
Software update/flashing
-
Emergency vehicle signal pre-emption
-
Work zone warning
​
​
-
Vehicles have a long life span, lasting several years in most cases. This makes it hard to change on-board systems as reaction to new upcoming risks to the vehicle safety.
-
Owners have constant physical access to and full control over vehicles. In spite of the involved safety risks, many users might try to modify or “enhance” their vehicles. From a manufacturer’s point of view, the risk of hardware tampering cannot be neglected.
-
No technical expertise on vehicle electronics or VC security aspects is expected from a user that runs a vehicle. Hence, the vehicular security measures have to operate autonomously with no need for intervention or feedback from the user.
-
Robustness requirements and time constraints are demanding. Functions necessary, for example, for driving or alerts received via the VC system must be processed in real-time: delays or errors could lead to vehicle malfunctions, driving errors, and consequently to physical damages and injuries.
-
Liability and conformance require precise formulation of legal issues. Differing regulations and requirements in various countries make it even more difficult to address these challenges.
​